Download Word gratuito • Edite on-line • Salve e compartilhe com Drive • Exporte para PDF
Um Acordo de Desenvolvimento e Publicação é um contrato entre um desenvolvedor (ou criador) e um publicador que financia, publica e distribui um produto (software, jogo, livro digital, conteúdo multimídia, etc.). O acordo especifica como o desenvolvedor será compensado (adiantamento, royalties ou ambos), quem é proprietário intelectual do produto, qual é o cronograma de entrega, e quais são as responsabilidades de cada parte. Este modelo Word editável oferece cláusulas prontas para propriedade intelectual, adiantamentos, plano de entrega, receita líquida, confidencialidade e direitos de distribuição — permitindo que pequenas editoras, produtoras e publicadores criem um contrato profissional sem custos de redação jurídica inicial. Você pode descarregar gratuitamente, editar on-line ou exportar em PDF.
Sem um acordo claro, disputas surgem rapidamente. Um desenvolvedor pode alegar que retém direitos autorais sobre código reutilizável; um publicador pode adicionar funcionalidades indefinidamente sem compensação extra; ou ambos podem discordar sobre como calcular royalties em vendas. Este contrato protege você ao deixar tudo por escrito: quanto é pago e quando, o que exatamente será desenvolvido, quem é proprietário de cada componente, e como receitas futuras são divididas. Ele também estabelece expectativas claras sobre prazos, testes de qualidade, confidencialidade e revisão — evitando atrasos e retrabalhos caros. Para publicadores, garante propriedade integral e direito de criar sequências ou adaptações. Para desenvolvedores, assegura compensação justa se o produto faz sucesso. É especialmente importante em projetos de médio a longo prazo, envolvendo financiamento significativo ou distribuição internacional.
| Se sua situação é… | Use este modelo |
|---|---|
| Projetos pequenos com um único pagamento de adiantamento no início | Acordo básico (adiantamento único) |
| Desenvolvimento de longo prazo com múltiplas fases de entrega | Acordo com pagamentos por marcos (milestone-based) |
| Quando o publicador quer opção de publicar produtos futuros do desenvolvedor | Acordo com direitos de primeira recusa |
| Quando o desenvolvedor recebe percentagem das receitas líquidas, não apenas adiantamento | Acordo com royalties por vendas |
| Quando a publicação é limitada a uma região geográfica específica | Acordo exclusivo por território |
| Quando há previsão de expansões, atualizações ou conteúdo adicional após lançamento | Acordo com produtos complementares (add-on) |
Por que importa: Permite interpretações conflitantes sobre funcionalidades, qualidade e compatibilidade, resultando em rejeição de entregáveis e disputas sobre pagamento.
Fix: Crie um anexo técnico detalhado (Inventário A) com funcionalidades, plataformas, linguagens de programação, padrões de desempenho e exemplos de tela ou prototipagem.
Por que importa: O desenvolvedor pode alegar que bugs encontrados após entrega são responsabilidade do publicador, bloqueando liberação de pagamentos.
Fix: Especifique claramente que o desenvolvedor é responsável por testes internos rigorosos; o publicador conduz testes de aceitação, e o desenvolvedor corrige bugs críticos em prazos definidos.
Por que importa: O desenvolvedor recebe dinheiro sem incentivo para entregar, ou o publicador bloqueia pagamentos baseado em critérios vagos.
Fix: Defina marcos específicos (ex.: 30% na assinatura, 40% após aprovação do protótipo, 30% ao lançamento) ligados a entregas tangíveis aprovadas por escrito.
Por que importa: A obrigação de guardar segredo pode ser indefinida, limitando a reutilização legítima de conhecimento do desenvolvedor em futuros projetos.
Fix: Especifique que confidencialidade expira 2–3 anos após término do contrato, exceto para segredos comerciais ou patentes (que podem ter proteção mais longa).
Por que importa: O publicador lucra com sequências, remasterizações e portes para outras plataformas sem pagamento adicional ao desenvolvedor.
Fix: Reserve cláusula que diferencia 'manutenção e correções de bugs' (responsabilidade do publicador, sem custo) de 'novos desenvolvimentos' (negociáveis e compensáveis).
Por que importa: O publicador adiciona requisitos continuamente, atrasando o projeto e tornando o adiantamento insuficiente para cobrir custos reais.
Fix: Estabeleça um processo formal (change order) para qualquer alteração de escopo, com ajuste de custo e prazo acordado por escrito antes da implementação.
Em linguagem simples: O publicador concorda em fornecer uma quantia inicial (adiantamento) ao desenvolvedor para cobrir custos de desenvolvimento, paga em parcelas conforme aprovação dos itens entregáveis.
O Publicador concorda em pagar ao Desenvolvedor um adiantamento contra royalties de [QUANTIA/MOEDA], a ser paga em parcelas sobre aprovação dos entregáveis no plano definido no Inventário B.
Erro comum: Não especificar claramente as condições para liberação de cada parcela (aprovação, data fixa, marcos técnicos), resultando em disputas sobre quando cada pagamento é devido.
Em linguagem simples: O título e todos os seus componentes são considerados obra criada por encomenda, sendo propriedade integral do publicador ou seus sucessores.
O Título e todas as revisões dele, se houver, e toda música original composta para e utilizada no Título são escritos e comissionados a pedido e direção do Publicador, e deve ser considerado trabalho por contratação.
Erro comum: Não deixar explícito se o desenvolvedor retém direitos residuais (como reutilizar código-fonte em projetos futuros), causando conflito após o lançamento.
Em linguagem simples: O publicador possui todos os direitos autorais, direito de criar obras derivadas, revisar, modificar e licenciar o título em qualquer formato atual ou futuro.
O Publicador deve ter todos os direitos no Título, incluindo o direito de fazer ou licenciar trabalhos derivados e o direito de produzir o Título e trabalhos derivados de todas as formas agora conhecidas ou futuramente desenvolvidas.
Erro comum: Deixar vaga a definição de 'obras derivadas', permitindo que o desenvolvedor crie versões modificadas ou sequências sem permissão.
Em linguagem simples: O desenvolvedor compromete-se a entregar componentes específicos (código, documentação, ativos) conforme o plano de entrega acordado, com funcionalidades definidas no anexo.
Itens Entregáveis deve ser cada componente de programa, material ou design definido no Plano de Entrega relevante que o Desenvolvedor deve entregar ao Publicador de acordo com os termos deste Acordo.
Erro comum: Não detalhar suficientemente as especificações técnicas, deixando margem para interpretações diferentes sobre qualidade, completude ou compatibilidade.
Em linguagem simples: O publicador pode optar por adicionar funcionalidades ou produtos complementares, com custo adicional estimado e possível ajuste no cronograma de entrega.
O Publicador deve ter a opção, à sua escolha, de adicionar [ESPECIFICAR] [PRODUTO] para as presentes especificações e orçamento.
Erro comum: Permitir que o publicador adicione requisitos indefinidamente sem limite de escopo, custos adicionais ou prorrogação do prazo.
Em linguagem simples: A receita líquida é o total de vendas menos devoluções defeituosas, custos de produção e impostos, sobre a qual incidem os royalties do desenvolvedor.
Receita Líquida deve ser toda receita reconhecida de acordo com a generalidade aceita contando os princípios relacionados à distribuição ou venda do Título, menos (a) unidades devolvidas como defeituosas, (b) Custo de Bens e (c) impostos pagos pelo Publicador.
Erro comum: Definir de forma vaga o que pode ser deduzido da receita bruta, permitindo que o publicador subtraia custos indiretos (marketing, overhead) que reduzem injustamente os royalties.
Em linguagem simples: Ambas as partes concordam em manter em sigilo informações sensíveis (código-fonte, planos de negócio, dados de clientes), exceto quando marcadas como 'confidenciais' por escrito.
Informação Confidencial deve significar informação de alguma das partes que seja revelada à outra parte de acordo com este Acordo, em forma escrita marcada como 'confidencial', ou se revelada oralmente, confirmada por escrita sumarizando tal informação dentro de [NUMERO] dias.
Erro comum: Não definir o prazo de validade da obrigação de confidencialidade, deixando em aberto se segredos comerciais devem ser protegidos indefinidamente ou por tempo limitado.
Em linguagem simples: O publicador possui direito exclusivo de revisar e modificar o título após conclusão, sem consentimento prévio do desenvolvedor.
O Publicador deve ter o direito de revisar o Título e o Desenvolvedor não deve ter qualquer direito de fazer revisões do Título completado sem o consentimento antecipado do Publicador.
Erro comum: Conceder ao publicador direito ilimitado de modificação sem especificar se o desenvolvedor recebe compensação adicional ou crédito pelos trabalhos modificados.
Em linguagem simples: O publicador tem direito exclusivo de distribuir o produto em todo o mundo, em qualquer formato ou plataforma, durante o período do acordo.
Território deve ser todo o mundo. O Publicador deve ter todos os direitos no Título, incluindo o direito de fazer ou licenciar trabalhos derivados e o direito de produzir o Título de todas as formas agora conhecidas ou futuramente desenvolvidas.
Erro comum: Não limitar a exclusividade de distribuição a um período definido ou não reservar direitos do desenvolvedor após término do contrato (ex.: venda de versão independente).
Em linguagem simples: O desenvolvedor é responsável por conduzir testes internos de qualidade para identificar e corrigir bugs antes de entregar ao publicador.
Teste QA deve ser o teste de garantia de qualidade de um alfa ou beta candidate ou gold master para identificação de bugs ou erros.
Erro comum: Não diferenciar claramente as responsabilidades: se o desenvolvedor testa apenas suas próprias compilações ou se também testa versões beta em dispositivos reais do publicador.
Preencha o nome legal, natureza jurídica (companhia, pessoa física) e endereço completo do publicador e do desenvolvedor. Certifique-se de que ambas as entidades têm capacidade legal para assinar contratos.
💡 Use nomes corporativos oficiais, não apelidos ou marcas comerciais informais.
Descreva detalhadamente o título ou produto a ser desenvolvido (software, jogo, livro digital, etc.), incluindo o nome, funcionalidades principais e formato de distribuição. Crie um anexo (Inventário A) com especificações técnicas completas.
💡 Quanto mais detalhes sobre o escopo, menos disputas sobre o que foi ou não desenvolvido.
Defina a quantia total em moeda, a divisão em parcelas e as condições para liberação (aprovação de marcos, datas específicas). Crie um Inventário B com o plano de entrega detalhado.
💡 Vincule cada parcela à aprovação de itens entregáveis concretos para evitar conflitos de pagamento.
Confirme que o produto é obra por encomenda, de propriedade integral do publicador. Se há exceções (ex.: o desenvolvedor retém direitos a componentes reutilizáveis), liste-as explicitamente.
💡 Registre propriedades intelectuais (marca, patente) no país de jurisdição logo após a assinatura.
Se o desenvolvedor recebe royalties sobre vendas (além de adiantamento), especifique a percentagem, o método de cálculo, frequência de relatórios e deduções permitidas (devoluções, impostos, custo de produção).
💡 Estabeleça um sistema de auditoria para que o desenvolvedor possa verificar os cálculos de receita do publicador.
Defina o que é considerado informação confidencial, prazo de proteção, responsabilidades em caso de vazamento, e qualidade exigida (testes QA, compatibilidade).
💡 Especifique sanções por violação de confidencialidade (multa, rescisão do contrato) para dissuadir vazamentos.
Confirme o territóri de distribuição (mundial ou limitado), duração dos direitos do publicador, e cláusulas sobre produtos futuros (direito de primeira recusa, opções de sequências).
💡 Defina uma data de expiração clara para os direitos exclusivos do publicador, após a qual o desenvolvedor pode negociar com outros.
Assegure que ambas as partes assinam todas as páginas e anexos. Mantenha cópias escaneadas assinadas por ambas as partes, com data e local de assinatura.
💡 Considere assinatura digital ou notarização, especialmente para contatos de alto valor.
O publicador é o proprietário legal. Este modelo segue a doutrina de 'obra por encomenda', na qual o desenvolvedor cria o produto sob supervisão do publicador, transferindo toda propriedade intelectual (incluindo código, gráficos, som, marca) ao publicador. O desenvolvedor não retém direitos autorais ou de cópia, a menos que cláusulas específicas reservem exceções (ex.: bibliotecas de código reutilizáveis). Após o término do contrato, o desenvolvedor não pode vender versões similares ou usar o mesmo código em projetos concorrentes, a menos que explicitamente permitido.
Existem duas abordagens principais. A primeira é um adiantamento único: o desenvolvedor recebe uma quantia fixa independentemente das vendas futuras. A segunda é royalties sobre vendas: o desenvolvedor recebe uma percentagem (ex.: 10–25%) da receita líquida (vendas totais menos devoluções, custos de produção e impostos). O modelo pode combinar ambas: um adiantamento que é recuperado pela publicadora, após o qual o desenvolvedor recebe royalties. Recomenda-se incluir cláusulas de auditoria para que o desenvolvedor possa verificar os cálculos de receita.
Depende do que está escrito no contrato. Normalmente, durante o desenvolvimento ativo, o desenvolvedor é esperado a dedicar tempo integral ou um percentual significativo ao projeto. Após o lançamento, se o desenvolvedor não tem obrigação contratual de manutenção contínua, pode trabalhar para outros. No entanto, cláusulas típicas de confidencialidade e não-concorrência podem proibir criar produtos similares por 1–2 anos. Sempre revise a seção de 'Não-Concorrência' para saber exatamente quais restrições se aplicam após término.
Conforme este modelo, o adiantamento é não-reembolsável. O desenvolvedor mantém o valor recebido, mesmo se o publicador decide não lançar o produto. Isso protege o desenvolvedor contra cancelamento arbitrário. No entanto, recomenda-se negociar uma cláusula que especifique circunstâncias legítimas (ex.: se o desenvolvedor falha cronicamente em entregar) que permitem ao publicador rescindir e recuperar uma parte do adiantamento.
O modelo prevê aprovação de entregáveis antes de liberar cada parcela de adiantamento. Recomenda-se: (1) definir claramente critérios de aceitação (funcionalidades listadas, testes QA passados, compatibilidade confirmada); (2) estabelecer um prazo para feedback (ex.: publicador tem 10 dias para revisar e solicitar correções); (3) permitir um número limitado de ciclos de revisão antes que sejam cobrados custos adicionais; (4) incluir arbitragem ou mediação se as partes não concordam sobre conformidade. Documentar tudo por escrito evita mal-entendidos posteriores.
Fortemente recomendado. Este modelo fornece uma base sólida, mas contém cláusulas legais complexas (propriedade intelectual, royalties, confidencialidade, rescisão) que variam conforme a jurisdição (Brasil vs. Portugal) e o setor específico (software, jogo, conteúdo, etc.). Um advogado especializado em propriedade intelectual pode garantir que direitos estão adequadamente protegidos, que deduções de royalties estão legais e que cláusulas de confidencialidade são exequíveis. O custo de uma revisão jurídica agora evita litígios caros depois.
O modelo é baseado em princípios comuns de direito contratual, mas nomenclaturas e requisitos legais diferem. No Brasil, propriedade intelectual é regida pela Lei 9.610/98; em Portugal, pela Lei 63/85. Recomenda-se: (1) ajustar a cláusula de jurisdição (tribunal competente); (2) especificar a lei aplicável (lei brasileira ou portuguesa); (3) revisar cláusulas de confidencialidade conforme regulamentações locais de proteção de dados. Consulte um advogado local antes de assinar.
Sim, o modelo é flexível o suficiente para livros, ebooks, audiolivros, podcasts, cursos on-line e conteúdo multimídia. Adapte a seção 'Título' para descrever especificamente o tipo de obra (ex.: "livro ilustrado de 250 páginas sobre [tema]") e as especificações (formato de arquivo, idiomas, resolução de imagens). Note que para livros, pode ser necessário adicionar cláusulas sobre direitos autorais de autores contribuintes, direitos de ilustrador, ou permissões de citação. Consulte o modelo 'Contrato de Publicação de Livro' se foca especificamente em literatura impressa ou ebook.
Este modelo é mais amplo e inclui componentes de publicação e distribuição (royalties, receita líquida, canais de distribuição). Um contrato de desenvolvimento puro trata apenas do código e entrega técnica. Este modelo é ideal quando o publicador também investe em marketing, distribuição e suporte pós-lançamento. Se você contrata um desenvolvedor apenas para codificar (sem que ele tenha envolvimento em publicação), considere um 'Contrato de Prestação de Serviços de Desenvolvimento' mais simples.
Um contrato de desenvolvimento simples cobre apenas a entrega de código e funcionalidades. Este modelo de publicação adiciona componentes de financiamento (adiantamento contra royalties), distribuição exclusiva, direitos autorais de longa duração, e mecanismos de compartilhamento de receita. Use o contrato simples se contrata um desenvolvedor apenas para completar um projeto técnico específico. Use este modelo se também planejai comercializar o produto, distribuir amplamente e manter direitos eternamente.
Um contrato de serviços genérico cobre atividades, prazos e pagamento por hora ou por projeto, sem mencionar propriedade intelectual ou royalties. Este modelo é específico para criação de obras autorais (software, conteúdo, design original), transferindo propriedade integral ao publicador e criando mecanismos de compensação futura. Escolha contrato de serviços se o trabalho é rotineiro (manutenção, suporte); escolha este modelo se o resultado é um produto original com potencial comercial de longo prazo.
Um contrato de licença permite que o desenvolvedor retenha propriedade mas concede permissão ao publicador de distribuir e vender por um período limitado, a troco de royalties ou taxa fixa. Este modelo de publicação, por outro lado, transfere a propriedade integral do publicador (obra por encomenda). Escolha licença se o desenvolvedor quer manter direitos e vender também a concorrentes; escolha este modelo se o publicador precisa controle total e planeja investimento significativo em marketing e suporte.
Uma parceria tipicamente distribui lucros e controle igualmente entre as partes, com decisões tomadas em conjunto. Este modelo estabelece uma relação assimétrica: o publicador financia, controla propriedade intelectual e decisões criativas, enquanto o desenvolvedor recebe adiantamento e potencialmente royalties. Use parceria se ambas as partes contribuem capital e expertise comparáveis; use este modelo se o publicador é o financiador primário e detentor de marca.
Publicadores de SaaS, apps móveis e software desktop podem usar este modelo para financiar e manter direitos autorais de produtos desenvolvidos por estúdios externos, estabelecendo royalties sobre assinaturas ou vendas.
Editoras de ebooks, audiolivros e conteúdo digital usam esta estrutura para contratar autores, ilustradores ou tradutores e manter direitos de distribuição em múltiplas plataformas (Amazon, Apple Books, Kobo).
Publisheres de jogos independentes financiam estúdios desenvolvedoras, assegurando propriedade intelectual de personagens, narrativas e mecânicas, além de direitos sobre sequências e produtos derivados (merchandise, filmes).
Plataformas de streaming e produtoras audiovisuais contratam cineastas e criadores independentes, mantendo direitos de difusão exclusiva e criação de conteúdo derivado (documentários, spin-offs, adaptações).
Plataformas de e-learning (Udemy, Coursera, educação corporativa) usam este modelo para contratar instrutores e criadores de conteúdo, definindo royalties por inscrição e direitos sobre reutilização em programas futuros.
Agências de design e experiência digital contratam desenvolvedores para criar aplicações, simuladores ou experiências imersivas, mantendo direitos de marca e permitindo adaptação para outros clientes ou verticais de negócio.
No Brasil, direitos autorais são regidos pela Lei 9.610/98, que exige transferência clara de propriedade para ser válida. Este modelo contempla 'obra por encomenda', mas recomenda-se que um advogado brasileiro confirme que cláusulas de propriedade intelectual estão alinhadas à lei federal e que royalties (se aplicáveis) respeitam direitos morais do criador. Considere também regulações de proteção de dados (LGPD) se o produto envolve dados pessoais.
Em Portugal, a Lei 63/85 regula propriedade intelectual e reconhece 'direitos morais' do autor mesmo após transferência de propriedade (direito à paternidade, à integridade da obra). Este modelo pode ser usado, mas recomenda-se adicionar cláusula respeitando direitos morais portugueses e especificar se créditos ao desenvolvedor serão inclusos no produto. Tambem valide conformidade com Lei de Proteção de Dados (Lei 67/98) se aplicável.
| Caminho | Melhor para | Custo | Tempo |
|---|---|---|---|
| Use o modelo | Projetos de baixo valor (<10 mil EUR/BRL), relação de confiança prévia, escopo simples e bem definido, entre partes em mesma jurisdição. | Gratuito a 50 EUR/BRL (download do modelo) | 2–4 horas para preencher, sem tempo de revisão jurídica |
| Modelo + revisão jurídica | Projetos de médio valor (10–50 mil EUR/BRL), escopo moderadamente complexo, múltiplas jurisdições ou direitos derivados envolvidos, desejo de proteção elevada. | 50–150 EUR/BRL (download) + 300–800 EUR/BRL (revisão jurídica simplificada) | 2–4 horas para preencher + 5–10 dias para revisão de advogado |
| Redigido sob medida | Projetos de alto valor (>50 mil EUR/BRL), royalties complexos, múltiplos produtos/extensões, disputas potenciais, direitos internacionais, conformidade regulatória específica (GDPR, direitos autorais). | 800–3000+ EUR/BRL (contrato inteiramente redigido por advogado especializado) | 2–4 semanas de negociação, redação e revisão |
Este documento é um dos 3,000+ modelos comerciais e jurídicos incluídos no Business in a Box.
Acesse mais de 3,000+ modelos empresariais e jurídicos para qualquer tarefa, projeto ou iniciativa.
Personalize seu modelo de documento empresarial pronto para uso e salve-o na nuvem.
Compartilhe seus arquivos e pastas com sua equipe. Crie um espaço de colaboração contínua.
"De um valor fantástico! Não sei o que faria sem essa plataforma. Vale cada centavo e valeu o investimento diversas vezes."
"Eu uso o Business in a Box há 4 anos. Tem sido a fonte mais útil de documentos que encontrei. Recomendo a todos."
"Salvou minha vida tantas vezes que eu perdi a conta. O Business in a Box me poupou muito tempo e, como você sabe, tempo é dinheiro."
Pare de baixar documentos. Comece a operar com clareza. Business in a Box fornece o sistema operacional usado por mais de 250.000 empresas no mundo para estruturar, gerenciar e expandir seu negócio.
Comece grátis · Não é necessário cartão de crédito
