Resumo

  • A política atual de marcas Rust trata do uso do nome, do logotipo, da origem apresentada e da aparência de afiliação; ela separa esse trabalho da governança do Projeto pelo Leadership Council.
  • Referência permitida, autorização escrita, fonte oficial indicada, decisão do Projeto, release revisado e implantação por terceiros são proposições independentes.
  • Um recibo de identidade e autoridade torna as proposições auditáveis sem criar uma aprovação nova nem julgar um crate, empresa ou produto específico.

Uma marca não carrega todas as decisões consigo

O nome Rust permite que pessoas identifiquem uma linguagem, ferramentas e fontes de software. Esse valor depende de não transformar o nome em credencial ilimitada. A Rust Language Trademark Policy diz que o projeto de código aberto Rust é governado por um Leadership Council e é administrado pela Rust Foundation, que possui e protege as marcas e logotipos Rust e Cargo. A frase descreve funções vizinhas, mas não intercambiáveis.

Administrar uma marca responde a uma pergunta pública: quem pode usar um sinal e que impressão esse uso transmite sobre origem, associação ou endosso. A governança do Projeto responde a perguntas sobre equipes, representantes, competências, políticas e delegações. Há ainda a pergunta sobre um artefato: quais bytes, qual commit, qual versão, quem revisou e quem declarou um release. Por fim, há a escolha de terceiros: alguém testou, comprou, instalou ou colocou o item em produção?

Um mesmo nome pode aparecer em todos esses contextos. Isso não converte uma resposta em prova das demais. “Compatível com Rust” é uma descrição delimitada. “Oficial”, “decidido pelo Projeto” e “implantado” acrescentam atores, decisões, objetos e datas que uma permissão de marca não fornece.

A política procura impedir aparência enganosa

A regra fundamental é que a marca Rust não pode ser usada de modo que pareça, para um observador casual, oficial, afiliada ou endossada pelo Projeto Rust ou pela Foundation sem permissão escrita da Foundation. A condição continua valendo mesmo nas categorias que não exigem aprovação explícita. Portanto, o foco é a identidade percebida, não uma certificação técnica de qualquer software que faça referência a Rust.

A mesma política permite, sem aprovação prévia, afirmar corretamente que um software foi escrito em Rust, é compatível com Rust ou contém código Rust. Também permite usar Rust em nomes de crates e repositórios quando isso descreve uso ou compatibilidade, e usar a forma cargo-foobar para uma subcomando que não se apresente como extensão oficial do Cargo. Essas permissões abrem espaço para descrição honesta num ecossistema aberto. Não demonstram que o Projeto escolheu a ferramenta, que uma equipe revisou seu código ou que um binário específico foi lançado pelo Projeto.

Alguns usos exigem aprovação explícita, como certas distribuições modificadas chamadas Rust ou Cargo, produtos com o logotipo, inclusão da marca em outra marca e nomes específicos de eventos. A necessidade ou concessão de autorização é, assim, um fato sobre aquele uso e suas condições. Não concede por acréscimo participação no Conselho, função de mantenedor, autoridade técnica ou garantia de resultado para usuários.

Fonte oficial é um fato de procedência limitado

A política lista domínios e a organização GitHub rust-lang como fontes legítimas de código-fonte e binários oficiais do Projeto Rust. Ela também alerta que nem tudo nesses domínios é oficial ou coberto pela política. Essa ressalva impede que o domínio vire uma prova total.

Uma fonte oficial responde onde o Projeto aponta seus códigos e binários oficiais. Não responde qual branch foi revisada, qual arquivo foi obtido, se aquele arquivo corresponde a uma versão publicada, quais dependências foram usadas ou se uma organização executa o resultado. Para isso, é preciso registrar artefato, versão ou digest e uma evidência própria de revisão, release ou operação.

Da mesma forma, uma autorização de marca não converte um repositório de terceiro em fonte oficial. A política permite que programas compatíveis sejam descritos com precisão sem incorporar todos eles à identidade institucional do Projeto. Essa é uma condição para compatibilidade voluntária, não uma recusa de reconhecimento.

A autoridade do Projeto percorre outro caminho

As regras publicadas do Leadership Council indicam que todas as equipes do Projeto terminam sob uma equipe de nível superior e que cada uma escolhe um representante. O consentimento é o método padrão do Council. As regras separam decisões operacionais internas de decisões públicas de política e reservam estas últimas, entre outras matérias, para elegibilidade de membros e decisores, política jurídica ou de licenças, compromissos contínuos assumidos em nome do Projeto e mudanças relevantes na estrutura jurídica ou na relação com a Foundation.

Esse caminho não promete resolver toda divergência técnica. Ele mostra, porém, que a autoridade do Projeto tem fonte e procedimento identificáveis. Uma pessoa, empresa ou ferramenta não passa a possuir essa autoridade porque seu emprego da marca é permitido. E uma decisão do Council não substitui as condições de uma licença de marca. Os sistemas podem cooperar, mas não são vouchers um do outro.

Os Bylaws da Foundation confirmam a divisão: apoiar e promover o Projeto, apoiar manutenção, desenvolvimento e segurança, gerir infraestrutura técnica e administrar a marca; o Projeto Rust é chamado de desenvolvedor principal da linguagem. Apoio e administração podem ser essenciais sem que a Foundation avalie cada código, o Council aprove cada uso de marca ou qualquer um deles decida uma instalação feita por um operador externo.

Um recibo para cada camada de uma alegação composta

Quando alguém reúne várias afirmações numa apresentação, um recibo de identidade e autoridade evita que uma delas empreste peso às outras. O primeiro bloco registra a marca exata, o usuário, o uso, a formulação pública, a necessidade de autorização e suas condições. O segundo registra a fonte alegada, repositório ou domínio, artefato e versão imutável, e se a descrição é oficial, compatível ou de terceiro.

O terceiro bloco só aparece se houver uma alegação de autoridade do Projeto: equipe ou processo do Council, decisão pública, escopo e data. O quarto mantém evidência de revisão e release: commit, registro de revisão, responsável pelo release, referência de build e estado. O quinto trata de uso posterior: teste, aquisição, instalação, produção ou nenhuma alegação, com quem pode corrigir o registro.

Nem toda referência a Rust precisa de todos os blocos. Um livro que menciona a linguagem com exatidão pode precisar apenas do primeiro. Uma integração apresentada como oficial requer origem e autoridade mais fortes. Uma alegação de produção precisa de evidência de operação. Campo vazio é honesto; preencher a lacuna com autoridade alheia não é.

O recibo não criaria uma política Rust, não faria da Foundation uma aprovadora de software e não transformaria o Council em registro de pacotes. Apenas impede que uma permissão sobre o nome seja lida como resposta para decisões sobre código, release ou implantação.

A repetição pode lavar a origem de uma afirmação

Uma permissão restrita pode virar, por repetição, selo aparente de revisão técnica. Uma página próxima a um domínio oficial pode virar prova aparente de release. Um evento comunitário pode parecer mandato. A frase curta passa de marketing para documentação, compras e operação, até que pareça comprovar a si mesma.

Se a permissão expira, o artefato é substituído, uma política muda ou o uso cessa, a correção de um único campo então parece negar toda a história. A disciplina mais barata é separar desde o início marca, autoridade, artefato e implantação. Assim, cada declaração leva apenas o peso de quem realmente a emitiu.

Fontes

  1. Rust Language Trademark Policy
  2. Rust Language Trademark Policy Updates, Explained
  3. Rust Foundation Bylaws
  4. Rust Project Leadership Council