5 pontos por GN⁺ 23 시간 전 | 3 comentários | Compartilhar no WhatsApp
  • Os direitos autorais de código assistido por IA dependem de haver contribuição criativa humana significativa; resultados feitos majoritariamente pela IA e quase sem intervenção humana podem não receber proteção
  • O critério central é meaningful human authorship; mais importante do que apenas indicar um objetivo é tomar decisões criativas como definir a arquitetura, filtrar resultados e reorganizar o código
  • Independentemente de haver ou não direitos autorais sobre o código, se existirem a work-for-hire doctrine ou cláusulas amplas de cessão de PI, código assistido por IA criado com tempo da empresa, equipamentos da empresa, projetos da empresa ou ferramentas licenciadas pela empresa também tem grande chance de pertencer à empresa
  • Mesmo havendo titularidade, a contaminação por licença open source é um problema separado; em especial, saídas que copiem na prática código da família GPL quase literalmente podem levar a violação de licença
  • Os eixos relativamente mais claros hoje são falta de autoria humana implica ausência de proteção, atribuição de direitos por contrato de trabalho e risco de cópia literal de código GPL; na prática, preservar registros e fazer varredura de licenças tende a ser mais importante do que esperar uma decisão judicial

Critérios de direitos autorais e zonas ainda não resolvidas

  • A proteção por direitos autorais se aplica apenas a obras criadas por humanos, e resultados gerados principalmente por IA, sem contribuição criativa humana significativa, podem não ser protegidos pelas regras atuais
  • Mesmo após o caso Thaler, a Suprema Corte não julgou o mérito; a decisão do DC Circuit foi mantida, mas ainda não há precedente direto aplicado exatamente a resultados de programação assistida por IA
  • A faixa central que os tribunais ainda não trataram diretamente é quanto de intervenção humana é necessário em uma obra assistida por IA
    • Diferentemente de uma imagem gerada puramente por IA, em que a intervenção humana é zero, no código muitas vezes há definição parcial de direção e aprovação humana, o que torna a fronteira mais difusa
    • Na área de código, ainda não existe decisão que aplique diretamente o princípio de autoria humana a saídas de ferramentas de programação com IA
  • Se o código criado pela IA foi aceito quase sem alterações, pode ser que ninguém consiga reivindicar direitos autorais sobre ele, e isso pode enfraquecer os meios de reação mesmo se um concorrente o copiar integralmente
  • O núcleo do critério é meaningful human authorship; mais importante do que só escrever o objetivo é o julgamento criativo de definir a estrutura, filtrar resultados e refazer o design

Como comprovar autoria humana

  • Contribuição humana significativa não é calculada de forma rígida por porcentagem ou número de edições; o que importa é se o humano realmente tomou decisões criativas
    • Escolha de arquitetura

      • É preciso decidir o que rejeitar entre os rascunhos
      • É preciso reorganizar o resultado para adequá-lo a um design específico
      • Se, após uma instrução curta como "crie um módulo de rate limiting para API", a ferramenta gerar vários arquivos e fizer revisões iterativas, ainda não há conclusão clara sobre se a contribuição humana seria suficiente em juízo
      • Um módulo bastante retrabalhado com mudanças de direção tem mais chance de ser reconhecido como autoria humana, enquanto código aceito como veio pode ser interpretado no sentido oposto
      • Allen v. Perlmutter continua sendo um ponto importante de inflexão sobre o grau de intervenção humana suficiente: mesmo com mais de 600 prompts e edições no Photoshop, os elementos básicos gerados por IA tiveram o registro negado
      • Em Zarya of the Dawn, apenas o texto escrito por humanos foi registrado, e as imagens criadas pelo Midjourney foram excluídas; esse princípio se aproxima da ideia de proteger separadamente os elementos feitos diretamente por humanos em uma base de código assistida por IA
      • Documentos de design servem como evidência
      • Decisões de design registradas em mensagens de commit também servem como evidência
      • ADRs também servem como evidência
      • Logs de prompts com rastros de mudanças deliberadas de direção também ajudam
      • Para ampliar a parte potencialmente protegível, é vantajoso registrar o que foi decidido diretamente por você e como isso foi alterado

O contrato de trabalho costuma definir a titularidade primeiro

  • Antes mesmo de discutir se o código é protegido por direitos autorais, é preciso verificar a quem esse direito pertence desde o início
  • Contratos de trabalho típicos atribuem à empresa os resultados produzidos dentro do escopo do trabalho, o que é explicado pela work-for-hire doctrine
  • Resultados criados no horário da empresa, em projetos da empresa, com equipamentos da empresa ou com ferramentas de programação com IA fornecidas pela empresa têm grande chance de ser tratados como propriedade da empresa, tanto código escrito manualmente quanto código assistido por IA
  • Na prática, os contratos geralmente são redigidos de forma ainda mais ampla do que a doutrina básica, e as formulações abaixo podem abranger também código assistido por IA
    • Obras criadas com equipamentos ou recursos da empresa também podem estar incluídas
    • Invenções ou desenvolvimentos feitos durante o período de emprego também podem estar incluídos
    • Software criado com ajuda de ferramentas licenciadas pela empresa também pode estar incluído
  • Em especial, a expressão company-licensed tools pode alcançar até projetos pessoais
    • Se a empresa adotou Claude Code, Cursor ou Copilot para uso da equipe
    • E você usou a mesma ferramenta em um projeto paralelo no seu tempo pessoal
    • Pode surgir espaço para a empresa reivindicar direitos sob uma cláusula ampla de cessão de PI
  • O texto afirma que não é convincente, do ponto de vista jurídico, dizer que a saída automaticamente se torna obra derivada de PI da empresa apenas porque o código da empresa estava aberto na IDE e a IA podia vê-lo
  • Ainda assim, se a redação contratual for ampla, pode surgir ao menos uma aparência plausível de reivindicação, independentemente do que a IA de fato tenha feito
  • Para separar projetos paralelos, é mais seguro manter o fluxo de trabalho totalmente isolado com conta pessoal, equipamento pessoal e ferramentas pagas pela própria pessoa

Risco de contaminação por licença open source

  • Mesmo que você seja dono do código criado pela IA, é uma questão separada saber se esse código trouxe consigo obrigações invisíveis de licenças open source
  • Ferramentas de programação com IA são treinadas com grandes volumes de código público, inclusive código sob licenças copyleft como GPL e LGPL
  • Licenças copyleft fazem com que, na distribuição de obra derivada daquele código, surja a obrigação de publicar sob a mesma licença
    • Se for derivado de código GPL, seu próprio código também pode ter de ser publicado sob a mesma licença
    • Alegar desconhecimento da licença não serve como defesa
  • O critério do risco jurídico não é similaridade funcional, mas cópia literal substancial e relevante
    • Um resultado que apenas se comporta como código GPL
    • E um resultado que reproduz código GPL quase literalmente são problemas diferentes
  • O risco se concentra mais na cópia literal, mas sem fazer varredura é difícil saber em qual dos dois lados a base de código atual se encontra
  • No início de 2026, na chardet community dispute, houve um caso em que o chardet foi reescrito com Claude e redistribuído sob licença MIT, gerando conflito sobre se isso poderia ser visto como uma implementação clean room
    • Esse caso foi uma disputa comunitária, não um processo judicial, portanto não houve conclusão jurídica definitiva
    • Ainda assim, já está consolidado que copiar literalmente código da família GPL caracteriza violação de licença
  • O ponto ainda não definido é se, quando uma saída de IA reproduz padrões dos dados de treinamento, isso deve ser considerado cópia literal
  • Em consultoria de fusões e aquisições, esse risco já é tratado como tema real, e varredura de licenças em bases de código com IA já entrou na lista de diligência
  • Doe v GitHub discute se o Copilot reproduz código licenciado sem atribuição, e o caso seguia em andamento no Ninth Circuit em abril de 2026
    • A primeira instância rejeitou a maior parte dos pedidos, mas o recurso continua
    • Independentemente do desfecho do processo, o GitHub adicionou duplicate detection filters e a prática do setor também mudou

O que fazer imediatamente na prática

  • Executar varredura de licenças

    • Em uma base de código assistida por IA, é importante primeiro rodar uma varredura de licenças open source
    • FOSSA — ferramenta abrangente amplamente usada no mercado enterprise
    • Snyk Open Source — boa integração com GitHub, o que facilita encaixe no fluxo de times de desenvolvimento
    • Black Duck — costuma ser padrão em diligência de M&A
    • Essas ferramentas fazem varredura da base de código para localizar correspondências com bibliotecas open source conhecidas e as licenças associadas
  • Registrar a contribuição criativa humana

    • Materiais que ajudam a comprovar autoria humana significativa já costumam surgir no processo normal de engenharia, mas seu valor aumenta se forem preservados intencionalmente
    • Mensagens de commit devem registrar o que foi mudado e por quê, mais do que simplesmente o resultado gerado pela IA
      • Registros como "Restructured Claude’s module architecture, rejected initial state management approach, rewrote error handling from scratch" ajudam como evidência
      • Se ficar apenas algo como "Add rate limiting module", será difícil demonstrar a contribuição humana
    • Também é recomendável guardar por exportação ou screenshot o histórico de interação do Claude Code e do Cursor
    • Documentos de design, ADRs e notas escritos antes do código gerado podem servir como indício de que a estrutura foi definida por humanos primeiro
  • Verificar cláusulas de PI no contrato de trabalho

    • É preciso revisar diretamente no contrato os itens intellectual property, IP assignment e work product
    • "Obras feitas no horário de trabalho" é mais estreito do que "obras feitas com recursos da empresa"
    • "Coisas relacionadas ao negócio da empresa" é mais estreito do que "todo desenvolvimento de software"
    • A expressão company-licensed tools pode conectar também o uso de ferramentas de IA em projetos pessoais
    • Para tocar um projeto independente
      • O ideal é negociar um carveout por escrito antes de começar
      • Separar totalmente equipamento pessoal, tempo pessoal e ferramentas pessoais
      • E talvez seguir adiante assumindo o risco de uma possível reivindicação da empresa
  • Verificar o tipo de termos da Anthropic

    • Antes de lançar comercialmente, convém consultar anthropic.com/legal e comparar consumer terms com commercial terms
    • free / Pro transferem ao usuário os direitos sobre as saídas, mas têm escopo mais estreito de IP indemnification
    • API / enterprise combinam cessão de direitos sobre as saídas com escopo mais amplo de defesa contra alegações de violação de direitos autorais ligadas ao uso aprovado e às saídas
    • Ainda assim, esse tipo de indenização não resolve por você um eventual problema de contaminação GPL dentro da base de código
    • Essa parte precisa ser gerida diretamente com varredura de licenças e governança interna

O que já está relativamente definido e o que ainda está em aberto

  • Hoje já existem três eixos relativamente claros
    • Obras sem autoria humana não recebem proteção por direitos autorais
    • A work-for-hire doctrine pode se aplicar independentemente da forma como o código foi gerado
    • Cópia literal de código GPL constitui violação de licença
  • Os dois pontos que os tribunais ainda não definiram claramente são
    • Em fluxos agentic, quanto de instrução e revisão humana é suficiente para haver autoria bastante
    • Se, quando a saída da IA reproduz padrões dos dados de treinamento, isso deve ser avaliado como cópia literal
  • Se essas questões vão se transformar em grandes litígios em breve ainda está no campo da pura especulação
  • Na prática, onde essa incerteza se torna problema primeiro não é no tribunal, mas em diligência de M&A e análise de investimento institucional
  • Compradores e investidores já estão fazendo essas perguntas como condição para fechar negócios, e mesmo que você não esteja nessa situação agora, ter registros e varreduras prontos desde já tende a ser vantajoso

3 comentários

 
undeadx1 16 시간 전

O código pode ser considerado objeto de proteção?

 
yeobi222 15 시간 전

Está incluído

 
Comentários do Hacker News
  • Isso deve ser visto no mesmo formato da jurisprudência sobre geração de imagens
    Como já foi definido em Zarya of the Dawn, os elementos escritos por humanos foram protegidos, mas as imagens geradas por IA não foram, e os designs de personagens selecionados, promptados e curados por humanos também não receberam copyright
    Acho que código não é diferente. Pedir ao Claude para criar uma função é mais próximo de pedir ao Midjourney para gerar um frame do que de eu mesmo escrever a função
    O motivo de engenheiros sentirem diferente geralmente é a analogia com compilador: compiladores são ferramentas determinísticas que produzem a mesma saída para a mesma entrada, e LLMs não são assim. A linha traçada pelo Copyright Office é justamente essa, e no caso das imagens essa conclusão veio primeiro

    • Então fico curioso se existe algo que de fato impeça uma pessoa de registrar copyright em seu próprio nome
      Também é ambíguo se o fato de outra pessoa poder reutilizar o mesmo prompt e reproduzir algo parecido invalida por si só a reivindicação de direitos da primeira pessoa
  • Cert denial não fixa a lei
    A Suprema Corte pode negar o pedido de revisão por muitos motivos que não têm relação com o mérito, então isso por si só não torna a questão settled no país inteiro

    • O TFA originalmente dizia isso
      O fato de a Suprema Corte não ter analisado o recurso de Thaler não significa que ela aprovou o raciocínio da instância inferior nem que chegou a uma conclusão nacional; significa apenas que a decisão do DC Circuit continua valendo, a posição do Copyright Office se mantém, e até agora não há tribunal que tenha decidido o contrário
      Mas o trecho citado agora não está mais no TFA
    • Acho que ainda faltam precedentes que testem essa conclusão de frente
      Não me vem à cabeça nenhum caso que confirme quais dos elementos listados bastam para reconhecer autoria
      Em especial, queria saber se já houve reconhecimento de autoria humana no ato de rejeitar repetidamente resultados e conduzi-los em outra direção
      O que está claro hoje é que as partes do código não escritas por humanos podem ser disclaimed, e de fato o Copyright Office exige divulgação e disclaimer. Gostaria de ver mais fontes citáveis sobre isso
    • Ainda assim, me parece que o efeito vinculante de precedente de tribunal de apelação continua valendo
      O principal efeito jurídico de reverter aquela decisão não seria justamente a perda desse valor de precedente?
      Em teoria, um precedente que não passou pela Suprema Corte pode sempre ser contestado, mas na prática a maioria funciona como lei até ser derrubada. Este caso não parece muito diferente
    • Não sei exatamente como se define meaningful human authorship
      Fazer code review é meaningful?
      Se eu modificar e editar o código gerado, isso conta como autoria humana?
    • A observação está correta, então editei o texto
      Cert denial significa apenas que a Suprema Corte não aceitou o caso, não que aprovou o raciocínio da instância inferior nem que decidiu a questão nacionalmente
      A decisão do DC Circuit continua em vigor e a posição do Copyright Office segue consistente, mas isso está mais para uma doutrina estável do que para uma regra fixada pela Suprema Corte
  • Acho que quem instruiu o agente deveria ter o copyright do resultado, mas também acho que a própria base que permitiu esse agente criar algo depende de PI apropriada indevidamente
    Especialmente em OSS, preocupa que esse modelo permita copyright washing, e por isso acho que desenvolvedores de OSS deveriam publicar sob a licença copyleft mais forte que conseguirem sustentar
    https://jackson.dev/post/moral-ai-licensing/

    • É curioso como a indústria do copyright foi trocando sorrateiramente copyright infringement por stealing como termo acusatório
      Se você ainda possui o original, o que exatamente foi roubado?
      Em Dowling v. United States, 473 U.S. 207 (1985), também se entendeu que venda não autorizada não era propriedade "stolen, converted or taken by fraud" sob o National Stolen Property Act
    • Acho que copyright laundering é quase uma fantasia
      Se um tribunal considerar a saída de um LLM suficientemente derivada, especialmente se esse LLM foi treinado com originais infringidos, então quem redistribuir essa saída derivada responderá por infração de copyright
      Criar o LLM pode ser transformativo, mas a saída infratora em si não é
    • Copyright não é um direito natural; é um regime concedido pelo Estado para promover o progresso da science and useful arts
      Então, se o copyright passa a atrapalhar esse progresso, me parece perfeitamente razoável criar exceções
    • Fico em dúvida se há realmente base legal para dizer que quem instruiu o agente tem o copyright
      Em Community for Creative Non Violence v. Reid(https://en.wikipedia.org/wiki/Community_for_Creative_Non-Violence_v._Reid), o fato de alguém encomendar o trabalho e dar direcionamento não torna essa pessoa autora; autor é quem efetivamente faz o trabalho
      É possível transferir direitos por contrato, mas depois de casos como o da selfie do macaco também ficou consolidado que copyright só é concedido a humanos
      LLM não é humano, então não pode ter copyright, e se não tem copyright legalmente, também não tem como transferir esse direito para você
    • Sinceramente, não entendo por que essa postura é tão difundida
      Quando escrevo código, também sou influenciado por incontáveis trechos que vi ao longo da formação e da carreira, e o LLM, nesse sentido, também refina suas saídas com base no código que viu
      A resposta imediata é: "esse código não tinha autorização para ser lido", mas essa lógica também não me convence muito. A maior parte do código com que aprendi tinha copyright, e salvo o meu código pessoal, os direitos quase sempre eram de outra pessoa. Até código confidencial sob NDA ou ligado à defesa nacional influenciou como eu programo depois
      Na arte é a mesma coisa. Fui influenciado por fotos de Ansel Adams, pinturas de Bob Ross e vários mestres, e peguei fragmentos vistos no trabalho dos outros para misturar com minha própria visão e criar algo diferente
      Isso não me leva a achar que alguém possa reivindicar direitos sobre meu resultado só por causa dessa influência
      Pessoas mais novas também aprenderam com meu código, e eu inclusive escrevi livros sobre desenvolvimento de software. Espero que um dia meu trabalho artístico também se torne algo que valha a pena ser assimilado por outros
      Muito antes de existirem LLMs, eu nunca quis que meu trabalho fosse selado comigo nem que minhas ideias fossem para o túmulo
      No fim, todos estamos sobre os ombros de gigantes, e sem absorver o trabalho anterior não teríamos realizado nem uma fração do que fizemos até agora
      Daqui a algumas décadas estarei morto e meu nome será rapidamente esquecido, mas se o software, as fotos e as pinturas que fiz deixarem ondulações no tempo, isso me parecerá uma pequena forma de imortalidade
  • Eu queria pedir que parassem de publicar comentários gerados no HN
    Isso não é permitido pelas regras, e já vi esse padrão mais de 30 vezes
    Claro, não posso ter 100% de certeza, mas considerando a análise de software e o padrão geral, parece bem convincente
    Veja https://news.ycombinator.com/newsguidelines.html#generated e https://news.ycombinator.com/item?id=47340079

    • A observação é justa, peço desculpas
      Usei um AI assistant na resposta e não vou usar de novo
  • A pergunta é divertida como exercício intelectual, mas na prática acho que no fim vai ficar com quem tem dinheiro
    Esperar que a Anthropic não possa ficar com o Claude Code só porque foi o Claude que escreveu parece mais pensamento positivo do que outra coisa

    • Além disso, a resposta provavelmente varia de país para país
      Nem todos os países favorecem implicitamente o lado mais rico, então é difícil prever o resultado
    • Se a discussão evoluir para algo como arte genAI não tem copyright, mas código genAI tem, então o Almighty Dollar estará realmente mandando
    • Intuitivamente, a tese de que a Anthropic seria dona parece mais bem explicada pela work-for-hire doctrine
      Mais do que se foi o Claude quem escreveu, o mais plausível é que a empresa detenha os direitos por causa dos contratos de trabalho dos engenheiros que o instruíram
      Já a questão dos pedidos de remoção via DMCA é mais interessante, porque a DMCA exige que o reclamante alegue de boa-fé ser titular do copyright
      Se mais tarde um tribunal entender que a base de código foi majoritariamente escrita por IA e portanto não é objeto de copyright, esses 8.000 takedowns podem ser contestados como pedidos de DMCA feitos de má-fé
      Como questão jurídica, isso é mais separável e mais concreto do que a discussão de titularidade
    • Isso não é só desejo: a titularidade também não está automaticamente definida
      No sistema jurídico dos EUA, parece relativamente claro que o modelo não é uma pessoa e, portanto, não pode possuir propriedade nem transferir contratualmente propriedade intelectual que nunca teve
    • Não acho que empresas fariam muita questão de ser donas de código malicioso, ilegal ou usado em crimes
      Mesmo assim, parece estranho que autoridades de investigação demonstrem tão pouco interesse no problema de o grok gerar CSAM ou revenge porn, então dá a impressão de que as empresas podem acabar ficando com o que é bom e evitando a responsabilidade pelo que é ruim
  • Do ponto de vista das empresas, isso parece uma abordagem bem esperta
    Primeiro usam claude code para criar, e só depois se preocupam em descobrir de quem é o código
    A gold rush que vejo ao meu redor revela a miopia da gestão. Os EMs da minha empresa também estão pressionando para todo mundo usar Claude o mais rápido possível
    Primeiro, depender demais do Claude Code faz você perder compreensão da base de código
    Segundo, isso destrói bons hábitos de desenvolvimento, como XP e code review. Agora é como se Claude revisasse o código do Claude
    Terceiro, isso prejudica o trabalho em equipe. Como fica mais fácil e barato para um único desenvolvedor tocar tudo do backend ao frontend, tarefas antes divididas entre time de FE e time de BE acabam se concentrando numa pessoa só
    Quarto, antes se dizia que o próprio código era a documentação e os comentários eram ignorados, mas agora, por causa do limite de contexto, temos de voltar a escrever explicações para o Claude. Quando uma pessoa não entendia, a culpa era dela; já para acomodar o contexto estreito do Claude, de repente aceitamos essa regressão, o que parece injusto
    Eu poderia continuar, mas no fim a força motriz dessa mudança cultural é dinheiro. Por isso chamo isso de gold rush e observo tudo com pipoca na mão

    • Parece que as pessoas esqueceram rápido demais
      Quando o Copilot apareceu, havia alertas claros para não usá-lo em código de empresa por causa da questão de licenciamento
      O que mudou agora? Foi a promessa da Anthropic de fazer defesa jurídica e indemnify?
    • Concordo em grande parte com o resto, mas uma pessoa projetar FE e BE juntos muitas vezes já era a melhor abordagem
      Backend e frontend precisam ser desenhados de forma acoplada, e separar os times às vezes aumenta o custo de coordenação
    • No longo prazo, parece fácil demais introduzir abstrações erradas
      Se o modelo mental na cabeça das pessoas for desaparecendo aos poucos, fica mais difícil explicar com responsabilidade como algo funciona durante uma falha e quais são os próximos passos
      Mesmo que generalizações equivocadas entrem no sistema, as IAs podem escrever, revisar e aprovar todo o código, e então já não fica claro quem está realmente no volante
    • O item #3 só raramente gera um resultado melhor
      Em geral, é melhor o time discutir junto os requisitos e as armadilhas, mas deixar a responsabilidade de implementação com uma única pessoa
  • O EU AI Act adiciona mais uma camada aqui
    O Article 50 exige divulgar ao usuário final quando um conteúdo foi gerado ou manipulado por IA, e essa obrigação de transparência recai sobre o deployer, não sobre o fornecedor do modelo
    Assim, mesmo que a questão do copyright acabe favorecendo quem fez o prompt, empresas que distribuem em escala resultados assistidos por IA continuam tendo um dever separado de divulgação
    A maioria ainda não está fazendo isso direito
    A questão de titularidade e a obrigação de divulgação são independentes, mas as organizações frequentemente misturam as duas

    • Mas fico na dúvida se código é conteúdo
      Essa cláusula parece mais voltada a coisas como vídeos gerados por IA para enganar pessoas, e não tanto a código de aplicação interna
  • Se você deu a uma ferramenta a especificação do código desejado, parece claro que já forneceu input criativo
    No fim, compiladores também não são algo parecido? Um LLM agent me parece uma ferramenta muito mais sofisticada que um compilador tradicional, capaz de produzir resultados a partir de especificações bem menos detalhadas

    • Mas o fato de você dar a um contratado humano a especificação do código desejado não foi repetidamente tratado pelos tribunais como input criativo para fins de copyright
      Para ser dono daquele código, você precisaria que o contratado cedesse explicitamente os direitos
    • Especificação nem sempre é input criativo
      Por exemplo, se eu só der o prompt "escreva um rate limiter em Python", não fui eu quem decidiu a API, nem o algoritmo de bucket de requisições, nem onde o contador será armazenado
      Eu apenas descrevi fatos, e fatos em si não são criativos por natureza
      Também há a diferença de que um compilador não faz com que o binário resultante seja tratado como uma obra separada. É semelhante a converter um formato de imagem em PDF e continuar tendo a mesma obra
      Já com um LLM não é assim. A entrada pode nem ser protegida por copyright, e a saída não é uma transformação mecânica: há escolhas envolvidas
      Na prática, se você rodar o mesmo prompt 10 vezes, pode obter 10 resultados significativamente diferentes
      Por isso, duvido que qualquer nível de prompting venha a ser reconhecido como criatividade suficiente
    • A analogia com compilador é um bom ponto de partida, mas o próprio Copyright Office tratou diretamente disso
      A questão central não é se você forneceu uma entrada, e sim se a expressão criativa da saída reflete autoria humana
      Num compilador tradicional, o programador é autor de toda a expressão do código-fonte; num LLM, o programador fornece a intenção, mas decisões expressivas como estrutura, nomes, padrões e implementação são tomadas pelo modelo
      Se essa diferença é juridicamente decisiva é exatamente o que está sendo discutido em Allen v. Perlmutter, e os memoriais de summary judgment previstos para o início de 2026 já foram concluídos, então a próxima decisão pode se tornar um marco
    • Para mim, isso no fim parece parecido com perguntar quem é dono do binário gerado por compilador
  • Tudo isso é interessante em teoria, mas na prática acho que em geral não importa muito
    Quase ninguém acredita seriamente que seu código seja um moat forte, e no dia a dia também existe pouca sensação de que ele seja objeto central de copyright
    Eu mesmo reutilizei pedaços de código semelhantes sob vários empregadores, e a maioria dos engenheiros provavelmente fez o mesmo. Também é comum usar código vindo de lugares como Stack Overflow sem tratar a titularidade com grande rigor
    Esse tema costuma aparecer em disputas ressentidas. O processo da Oracle contra o Google por o Android imitar demais suas APIs é o exemplo clássico, e a Suprema Corte acabou considerando isso fair use
    Também já houve casos de hedge funds de alta frequência processando ex-funcionários, e nos EUA qualquer pessoa pode processar outra por quase qualquer motivo
    Então é possível haver uma briga do tipo Ellison contra Page e Brin até a Suprema Corte, mas em 99,9% dos casos a sensação é que isso não muda quase nada no mundo real
    https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf

    • Quando você vai para o lado da gestão não técnica, a visão muda de forma surpreendente
      Muita gente enxerga código como uma PI gigantesca e como segredo comercial
      Como CTO, quando digo que "em geral, código não é um segredo tão extraordinário assim", frequentemente recebo olhares chocados
      Uma empresa quase desistiu de um grande contrato que exigia compartilhamento de código-fonte sob NDA, mas quando expliquei por que aquilo era uma reação exagerada, eles entenderam
      Ainda assim, essa mentalidade antiga continua muito forte
    • Acho estranho ninguém falar de convergence
      É justamente disso que estamos falando: se todos os caracteres do código necessário já estão, na prática, predeterminados pelas APIs que precisam ser usadas, então não há expressão artística nem copyright ali
      Mas se você estiver projetando uma API totalmente nova, isso sim pode ser protegido
    • Todas as licenças de código aberto se baseiam na premissa de que código é protegido por copyright
    • A ideia de que "código não é objeto de copyright" me parece bem incomum
      Talvez os trechos curtos do seu exemplo não sejam, mas em escalas maiores tanto empresas quanto indivíduos geralmente entendem que código é propriedade intelectual sob a lei de copyright
      Se código não fosse objeto de copyright, de onde o GPL tiraria sua força?
      Por exemplo, por que bastaria a suspeita de que código da Microsoft possa ter entrado no ReactOS para colocar o projeto durante meses ou anos em locked-down review mode?
      Por que empresas explicitariam em contratos de trabalho a titularidade do copyright do código?
      Na prática, tirando APIs, interoperabilidade e implementações excessivamente triviais, quase todo mundo reconhece a proteção autoral do código
    • Se não fosse assim, por que existiria clean room implementation?
      Pergunte a desenvolvedores de emuladores ou do ReactOS
      https://reactos.org/forum/viewtopic.php?t=21740
  • Também há exceções à frase "se o Claude Code ou o Cursor geraram e você não modificou de forma significativa, talvez ninguém tenha copyright sobre esse código"
    Se esse código reproduzir literalmente um trecho substancial de uma obra já existente, o autor original ainda poderá reivindicar seu copyright, e isso rapidamente vira uma questão de infração