Citar software exige identificar o objeto utilizado: criador ou organização responsável, nome, versão, data, tipo de recurso e um endereço ou identificador persistente quando existir. Escrever apenas “os dados foram analisados no R”, “usou-se SPSS” ou colocar o endereço da página inicial não informa qual versão produziu o resultado. A citação precisa caminhar junto da descrição metodológica: no método, explique o papel do programa e os procedimentos executados; na referência, identifique o software para que outra pessoa consiga localizar o objeto correto.
Os princípios de citação de software da FORCE11 defendem importância, crédito e atribuição, identificação única, persistência, acessibilidade e especificidade. Isso significa tratar software como produto de pesquisa citável quando ele influencia o trabalho, e não escondê-lo atrás de uma menção genérica. O formato final continua dependente das normas da instituição, da revista e do estilo adotado.
Decida o que precisa ser citado e onde aparece
Nem todo aplicativo aberto durante o projeto exige uma referência formal. A pergunta é se o software teve papel material na produção, transformação, análise ou interpretação dos resultados. Um editor usado apenas para digitar pode não precisar aparecer. Já um pacote estatístico, uma biblioteca que implementa o modelo, um programa de simulação, um algoritmo de processamento ou um código criado para o estudo afeta o método e merece identificação.
Distinga três situações. Na primeira, o software é uma ferramenta: informe versão e função, como “a análise descritiva foi executada no programa X, versão Y”. Na segunda, um pacote ou módulo específico implementa uma técnica: cite o pacote, não apenas o ambiente principal. Na terceira, o próprio software é um resultado da pesquisa: descreva autoria, repositório, versão arquivada, licença e documentação de uso.
Se o programa indicar uma citação preferencial, leia-a. Muitos projetos exibem “Cite this software”, arquivo CITATION.cff, artigo metodológico ou comando que gera referências. A recomendação do desenvolvedor ajuda, mas ainda precisa corresponder ao objeto usado. Citar apenas o artigo sobre o software pode dar crédito ao método sem identificar a versão executada; em alguns casos, artigo e software devem aparecer juntos.
Colete os dados da versão durante a análise
Registre a versão quando o resultado for produzido, e não meses depois. Procure menu “Sobre”, saída de sessão, gerenciador de pacotes, arquivo de ambiente, página de release, tag ou commit. Em ambientes como R ou Python, anote também versões de pacotes relevantes. Para código em evolução sem release, o hash do commit pode ser a identificação mais específica, mas um depósito com DOI oferece persistência adicional.
Crie uma ficha com autor ou organização, título do software, versão, data da versão, tipo, responsável pela distribuição, repositório, DOI ou URL e data de acesso quando exigida. Guarde evidência: captura da versão, arquivo de ambiente ou saída de comando. Essa ficha alimenta a referência e a metodologia replicável.
Não invente ano a partir do copyright geral do site nem trate a data do acesso como data de lançamento. Se o projeto não informa um elemento, siga a regra do estilo para ausência de data e registre o limite. Um repositório ativo pode mostrar a data do commit; isso não significa automaticamente que seja a data oficial de uma versão.
Monte a referência a partir do objeto, não da marca
A ordem e a pontuação variam conforme o estilo, mas a referência precisa preservar os elementos identificadores. Uma estrutura de trabalho pode ser: AUTOR OU ORGANIZAÇÃO. Título do software: subtítulo, se houver. Versão. Local ou responsável pela distribuição, data. Tipo do recurso. Identificador persistente ou endereço.
Exemplo fictício de estrutura, que deve ser adaptado à norma do curso: “SILVA, Ana; COSTA, Rui. AnalisaTexto. Versão 2.4. 2026. Software. DOI: 10.xxxx/xxxxx.” O exemplo mostra a lógica, não fornece um DOI real. Nunca copie identificadores inventados para a bibliografia. Quando o software possui DOI, abra-o e confira se título, autores e versão coincidem.
Para software comercial, a organização pode ocupar o papel de responsável, e a página oficial pode ser o destino disponível. Inclua a versão exata e o sistema ou módulo quando isso afetar o resultado. Para pacote aberto, prefira release, repositório arquivado ou registro persistente à página inicial da documentação. Para código próprio, crie uma versão, documente autoria e, quando apropriado, deposite-a antes de citar.
Diferencie a referência da descrição do procedimento
A citação não reproduz o método. “Utilizou-se o software X” ainda deixa dúvidas sobre importação, limpeza, parâmetros, funções e decisões analíticas. No método, descreva entradas, etapas, opções relevantes, pacote ou função e saída usada. Em análise estatística, informe modelo, estimador, tratamento de ausências, nível de confiança e verificações; o nome do programa não substitui essas escolhas.
Também não transforme a referência em tutorial técnico. Ela identifica; a documentação do projeto explica como executar. Se o código faz parte da contribuição, um README deve indicar dependências, ordem dos scripts, arquivos de entrada e saídas esperadas. A versão citada precisa conservar essas informações.
Ao relatar vários pacotes, evite uma lista de nomes sem função. Relacione cada um à etapa correspondente: leitura, limpeza, análise, visualização ou exportação. Se uma dependência transitiva não foi chamada diretamente e não afetou uma decisão reportada, talvez baste preservá-la no arquivo de ambiente, sem sobrecarregar o texto principal.
Confira persistência, acesso e crédito
Um endereço de branch pode mudar. Uma página de documentação pode passar a mostrar a versão mais nova. Prefira DOI de versão, release arquivada, tag estável ou commit específico quando possível. O grupo de citação de software da FORCE11 registra os princípios e o trabalho desenvolvido para consolidar práticas entre disciplinas; eles ajudam a avaliar se a referência entrega identificação e acesso suficientes.
Confira também os autores. Software pode ter muitos contribuidores, uma equipe institucional ou uma citação recomendada diferente da lista completa de commits. Siga o registro oficial e as regras do estilo sem apagar crédito por conveniência. ORCID, quando presente, reduz ambiguidade, mas precisa pertencer à pessoa correta.
Uma auditoria final pode ser feita em cinco passos:
- liste programas, pacotes, scripts e serviços que influenciaram resultados;
- identifique função, versão, data, autores e fonte de cada objeto material;
- registre o procedimento no método e a identificação formal nas referências;
- abra DOI, release, tag ou commit e confira se recupera a versão usada;
- teste se outra pessoa consegue relacionar software, parâmetro, arquivo de entrada e resultado.
A referência deve acompanhar a vida do projeto
Se a análise for refeita com versão nova, atualize a ficha, confira mudanças e registre o que foi reexecutado. Não altere a referência apenas porque o site do software mudou; ela deve continuar apontando para o objeto que produziu os resultados publicados. Em correções, preserve a trilha entre versão anterior e nova.
Para projetos próprios, forneça instruções de citação e uma versão arquivada. Um arquivo CITATION.cff pode tornar os metadados legíveis por pessoas e ferramentas. O objetivo final não é preencher mais uma entrada bibliográfica, mas conservar crédito, método e recuperabilidade no mesmo registro. Quando alguém abre a referência, identifica a versão e entende seu papel na análise, a citação cumpriu sua função.
Guarde essa ficha junto aos dados e ao script principal, e não apenas no gerenciador bibliográfico. Se outra pessoa importar a referência sem conhecer o projeto, ela ainda deve encontrar a versão, a licença e o local persistente. Essa redundância documentada protege o vínculo entre a bibliografia final e o ambiente que gerou as tabelas efetivamente apresentadas.
