Download Word gratuito • Edite on-line • Salve e compartilhe com Drive • Exporte para PDF
Um modelo Desenvolvimento Multimídia e Acordo de Licença é um contrato entre um cliente (editora, produtor de conteúdo, empresa) e um desenvolvedor de software para a criação de programas multimídia interativos — como aplicações, jogos, conteúdo digital interativo ou software customizado. O contrato detalha o escopo de trabalho em marcos técnicos mensuráveis, a forma de compensação (tempo e materiais, mais royalties sobre futuras vendas), direitos de propriedade intelectual e licença limitada concedida ao cliente para distribuir o programa. É um contrato mestre que pode ter múltiplos aditivos (Acordos de Programa) para diferentes projetos sob os mesmos termos base. Disponível como download Word gratuito, totalmente editável, exportável em PDF.
Sem um acordo formal claro, desenvolvedores e clientes frequentemente discordam sobre o que foi prometido, quanto custa e quem é dono do código e dos royalties futuros. O resultado é atraso, trabalho não-pago, propriedade intelectual contestada e, em casos graves, litígio custoso. Este modelo protege ambas as partes ao estabelecer: (1) escopo preciso em uma especificação aprovada; (2) marcos técnicos com datas e entregáveis claros; (3) compensação estruturada em tempo/materiais e royalties; (4) propriedade intelectual definida — o desenvolvedor retém propriedade, o cliente recebe licença para distribuir; (5) direito de auditoria — o desenvolvedor pode verificar números de vendas e royalties pagos. Para empresas que contratam desenvolvimento regularmente, a estrutura de "Acordo Mestre + Aditivos de Programa" economiza tempo e reduz risco legal em múltiplos projetos.
| Se sua situação é… | Use este modelo |
|---|---|
| Quando haverá múltiplos programas desenvolvidos sob o mesmo contrato base | Acordo mestre com aditivos de programa |
| Para projetos únicos e menores, sem necessidade de marcos ou royalties | Acordo simplificado de desenvolvimento |
| Quando a compensação é uma taxa única, sem receitas futuras envolvidas | Acordo com pagamento fixo (sem royalties) |
| Quando o cliente adquire direitos exclusivos sobre o programa desenvolvido | Acordo de licença exclusiva |
| Para projetos com tecnologia proprietária ou conteúdo sensível | Acordo com cláusulas de confidencialidade reforçadas |
Por que importa: Desenvolvedores e editoras discordam posteriormente sobre o que estava incluído, causando atrasos, custos extras e litígios.
Fix: Sempre anexe uma Especificação escrita e detalhada, aprovada por ambas as partes, ao Acordo de Programa antes do desenvolvimento começar.
Por que importa: Editora paga royalties sobre números diferentes, desenvolvedor recebe menos do acordado, levando a disputas contínuas.
Fix: Detalhe com precisão: 'Receita Líquida = valores recebidos menos devoluções, descontos legítimos e impostos, excluindo custos internos da editora'.
Por que importa: Desenvolvedor realiza trabalho extra sem ser pago, margens desaparecem, relação comercial deteriora.
Fix: Exija aprovação escrita e estimativa de custo antes de qualquer mudança de escopo; atualize o Acordo de Programa.
Por que importa: Sem dados claros, é impossível verificar se royalties pagos estão corretos; desenvolvedor não consegue auditar.
Fix: Editora deve fornecer relatório mensal de vendas, unidades instaladas por programa e receita total por categoria.
Por que importa: Desenvolvedor pode reclamar propriedade sobre partes reutilizáveis; editora pode ser impedida de modificar ou vender.
Fix: Defina claramente: desenvolvedor é dono do programa, editora tem licença limitada para distribuir; reutilizáveis permanecem propriedade do desenvolvedor.
Por que importa: Erros de cálculo ou omissão de vendas passam desapercebidos; desenvolvedor perde royalties ao longo do tempo.
Fix: Agende auditoria anual ou a cada dois anos; use um auditor independente se valores forem significativos.
Em linguagem simples: Define os serviços que o desenvolvedor prestará e que cada programa será descrito em um Acordo de Programa separado com plano próprio.
A Companhia retém o Desenvolvedor para realizar serviços e entregar um Programa ou Programas. O Escopo do trabalho de cada Programa será definido no Acordo de Programa.
Erro comum: Não descrever com precisão o escopo, levando a conflitos sobre o que está ou não incluído no desenvolvimento.
Em linguagem simples: O desenvolvedor prepara uma proposta com especificações técnicas, recursos da equipe e cronograma de marcos, sujeita a aprovação e incorporada no aditivo.
Cada Plano de Programa será enviado à Companhia para aprovação, e após a aprovação, será incorporado no Acordo de Programa. A Especificação irá ter uma definição do escopo e características funcionais do programa.
Erro comum: Aprovação informal ou não-documentada de planos, causando discordância posterior sobre escopo e preço.
Em linguagem simples: A editora paga ao desenvolvedor por tempo e materiais conforme tabela de taxas, mais royalties. Faturas mensais são apresentadas e pagas em 30 dias.
A Companhia deve pagar ao Desenvolvedor em bases de tempo e materiais usando um planejamento de taxas definidos no Inventário [ESPECIFICAR] anexado a este e incorporado aqui, e um royalty, como definido na Seção [NUMERO].
Erro comum: Não definir claramente se o pagamento é fixo ou variável, gerando disputas sobre custos adicionais.
Em linguagem simples: Solicitações de funcionalidades não previstas na especificação original requerem aprovação e cálculo de custos adicionais antes de serem incorporadas.
Se durante o curso do desenvolvimento, a Companhia requisitar ou o Desenvolvedor recomendar a inclusão de capacidades que não estavam inclusas na Especificação, o Desenvolvedor irá apresentar para Companhia para sua aprovação o custo adicional projetado.
Erro comum: Realizar mudanças de escopo sem formalizar custos adicionais, resultando em perda de margem para o desenvolvedor.
Em linguagem simples: O desenvolvedor é reembolsado por despesas autorizadas, exceto secretariado, cópias excessivas e refeições não-relacionadas a viagem.
O Desenvolvedor será reembolsado pela Companhia por gastos autorizados e razoáveis ocorridos pelo Desenvolvedor em conexão com o desempenho de seus serviços, dado que o Desenvolvedor mostre à Companhia com razoáveis contas.
Erro comum: Incluir despesas não-autorizadas ou pessoais, levando à rejeição de reembolso e conflitos sobre documentação.
Em linguagem simples: Para cada programa, a editora paga percentual mensal ou anual da receita líquida ao desenvolvedor, acompanhado de relatório de vendas e unidades instaladas.
Para cada Programa desenvolvido sobre este Acordo Mestre, a Companhia irá pagar ao Desenvolvedor um royalty igual a porcentagem da Rede da Companhia [ESPECIFICAR A MOEDA] de Receitas, tal porcentagem definida no Acordo de Programa.
Erro comum: Definir base de cálculo de royalties ambígua (receita bruta vs. líquida), levando a discordâncias contínuas.
Em linguagem simples: O desenvolvedor reserva o direito de auditar anualmente os livros da editora para verificar receitas e royalties devidos.
O Desenvolvedor reserva o direito de auditar os livros e registros anuais da Companhia a fim de verificar a Rede de Receita em [MOEDA] do Produto e royalties devidos.
Erro comum: Não exercer direito de auditoria regularmente, permitindo que erros ou subaproveitamento de royalties passem desapercebidos.
Em linguagem simples: O desenvolvedor retém direitos sobre o programa, mas concede à editora uma licença limitada para reproduzir, distribuir e mostrar o programa conforme definido.
O Desenvolvedor e Companhia reconhecem que todo direito, título e interesse em tais programas devem ser do Desenvolvedor e Companhia nos termos e condições definidos aqui.
Erro comum: Não esclarecer claramente quem é dono de cada elemento (código, arte, documentação), gerando conflitos futuros.
Em linguagem simples: Cada entrega associada a um marco deve ser aprovada pela editora conforme as especificações antes de ser considerada completa.
E entrega associada com cada marco na Programação de Marcos será conforme a então Especificação e será enviada à Companhia para sua aprovação e concordância de que ela está conforme com as Especificações ('Aceitação').
Erro comum: Deixar de formalizar aceitação, permitindo que o desenvolvedor prossiga sem confirmação de conformidade.
Preencha o nome completo, estrutura legal (corporação, LLC, etc.) e endereço da sua empresa (Publicador/Cliente) e do desenvolvedor (Desenvolvedor). Verifique se os dados comerciais e de registro estão exatos.
💡 Use o nome legal registrado na sua autoridade comercial, não apelidos ou marcas.
No Inventário de Taxas (Anexo), descreva o método de pagamento: valor por hora, valor por desenvolvedor, valor por marco ou combinação. Indique a moeda e as condições de pagamento (ex: net 30 dias).
💡 Se usar múltiplas categorias de pessoal (senior, junior, etc.), liste as taxas separadamente.
Para cada programa, o desenvolvedor preparará uma Programação de Marcos. Inclua desenho, protótipos, versão beta, testes e versão final. Dê datas realistas.
💡 Marcos mensuráveis facilitam a aprovação e o pagamento — evite marcos vagos como 'em progresso'.
Se o programa será vendido ou licenciado, especifique a porcentagem de royalty (ex: 10% da receita líquida). Defina como 'Receita Líquida' — excluindo devoluções, descontos e impostos.
💡 Royalties de 5–15% são comuns; ajuste conforme a complexidade e exclusividade do programa.
Esclareça exatamente quais receitas contam: venda direta, licenças? Excluem devoluções, descontos, impostos, transporte? Seja específico para evitar disputas futuras.
💡 Inclua definição de como royalties são calculados se o programa for vendido com outros produtos (pró-rata).
Especifique se royalties são pagos mensalmente, trimestralmente ou anualmente. Indique a data limite (ex: até dia 30 do mês seguinte) e exija relatório de vendas anexado.
💡 Relatórios detalhados de vendas e unidades instaladas facilitam auditorias e reduzem conflitos.
O desenvolvedor tem direito de auditar os livros da editora. Especifique a frequência (anualmente, a cada dois anos), prazo de retenção de registros (ex: 3 anos) e quem paga a auditoria se houver discrepâncias.
💡 Uma cláusula de auditoria com custo a cargo do auditado em caso de erro protege seu direito a royalties.
Leia o contrato completo, verifique placeholders preenchidos, datas e valores. Ambas as partes devem assinar (digital ou papel). Mantenha cópias assinadas para ambos os lados.
💡 Considere ter um advogado revisar antes de assinar, especialmente se houver valores altos ou termos incomuns.
Sim, o desenvolvedor retém a propriedade intelectual do programa. A editora recebe uma licença limitada para reproduzir, distribuir e mostrar o programa, conforme definido no acordo. Isso significa que o desenvolvedor pode reutilizar partes do código em outros projetos (a menos que o contrato estabeleça exclusividade), mas a editora não pode modificar o programa ou vendê-lo sem permissão. Alguns contratos podem transferir propriedade total para a editora em troca de pagamento mais elevado.
Marcos são pontos de referência mensuráveis no cronograma de desenvolvimento, como conclusão do design, protótipo funcional, versão beta, testes e versão final. Cada marco deve ter uma data e um entregável tangível (documento de design, código-fonte, versão executável, etc.). O contrato exige que a editora aprove cada entrega conforme os marcos, antes de o desenvolvimento prosseguir. Marcos bem-definidos facilitam o rastreamento do progresso e justificam os pagamentos parciais.
O contrato não especifica penalidades por atrasos, mas é recomendável adicionar cláusulas sobre extensão de cronograma ou rescisão. Em geral, se o desenvolvedor não entregar dentro de um período razoável (ex: 30 dias após a data de vencimento), a editora pode rescindir o contrato, suspender pagamentos futuros e, dependendo da lei, reclamar indenização. Adicione disposições sobre situações de força maior (desastres naturais, ausência do desenvolvedor por doença, etc.) que podem justificar atrasos.
O contrato oferece um método pró-rata: se o programa for vendido como um pacote com outros produtos, o royalty é calculado aplicando a porcentagem acordada apenas à proporção da receita atribuída a esse programa específico. Por exemplo, se o pacote custa 100 e metade é atribuída ao programa (50), o royalty de 10% é pago sobre 50, não sobre 100. A editora e o desenvolvedor devem acordar sobre como atribuir preços aos componentes; idealmente, usando preços de venda separados ou uma fórmula clara.
Um contrato de prestação de serviços genérico cobre apenas trabalho realizado e honorários. Este modelo inclui elementos adicionais específicos do software: marcos de desenvolvimento, especificações técnicas, direitos de licença, royalties futuros sobre vendas, direito de auditoria e propriedade intelectual. É essencial quando há compartilhamento de receita futura ou quando a editora venderá o programa a terceiros.
O contrato estipula que os livros devem ser mantidos por um período especificado (você preenche com [NUMERO], tipicamente 3–5 anos) após cada pagamento de royalty ou até o término do contrato, o que for mais recente. Isso permite que o desenvolvedor faça auditorias retroativas se questionar números. Registros mais antigos geralmente podem ser descartados conforme as leis fiscais locais, mas manter 3–5 anos oferece proteção suficiente.
Se não houver vendas, não há royalties a pagar — o desenvolvedor recebe apenas a compensação fixa pela fase de desenvolvimento. Isso é um risco comercial que o desenvolvedor assume. Para mitigar, alguns desenvolvedores negoceiam um "avanço mínimo" contra royalties (ex: pagamento mínimo anual garantido) ou um período de exclusividade limitado para a editora antes de o desenvolvedor poder oferecer o código a outros clientes.
Sim, a menos que o contrato conceda exclusividade. Por padrão, o desenvolvedor pode reutilizar estruturas, bibliotecas e técnicas genéricas em futuros clientes. Porém, se o programa usa componentes proprietários únicos ou conteúdo específico do cliente (arte, narrativa), esses permanecem propriedade do cliente se encomendados especificamente. Para evitar conflitos, defina claramente o que é reutilizável (framework técnico) vs. exclusivo (conteúdo e funcionalidades sob encomenda).
O desenvolvedor contrata um auditor independente para examinar os livros da editora, verificar receitas de vendas e calcular royalties devidos. Custos de auditoria normalmente são pagos pelo desenvolvedor. Porém, se a auditoria revelar discrepância significativa (ex: royalties não pagos ou errados), muitos contratos estipulam que a editora paga os custos de auditoria. Acordos bem estruturados exigem que a editora coopere e forneça acesso aos registros em prazo razoável.
Um contrato de prestação de serviços genérico cobre trabalho realizado e honorários únicos, mas não especifica direitos de licença, royalties futuros ou marcos técnicos. Use este modelo quando haverá compartilhamento de receita futura ou quando a editora venderá o programa a terceiros. Use um contrato simples de serviços se o cliente apenas quer o código pronto para uso interno sem revenda.
Em um WMH, o cliente é automaticamente dono de tudo o que foi criado; o desenvolvedor não retém direitos. Este modelo é o oposto: o desenvolvedor retém a propriedade e concede licença ao cliente. Use WMH se o cliente quer propriedade exclusiva e não quer pagar royalties futuros. Use este modelo se o desenvolvedor quer reutilizar código ou vender para múltiplos clientes.
Um contrato SaaS cobre assinatura contínua a um serviço hospedado na nuvem. Este modelo cobre desenvolvimento de programas multimídia com royalties sobre vendas de licença. Use SaaS para serviços recorrentes e assinatura; use este modelo para venda de cópias ou licenças de software tradicional.
Open source permite que qualquer pessoa use, modifique e distribua código livremente sob uma licença pública (MIT, GPL, etc.). Este modelo é comercial e proprietário: a editora precisa de uma licença formal do desenvolvedor. Use open source para projetos comunitários sem royalties; use este modelo para software comercial com compensação e royalties.
Essencial para contratos de desenvolvimento customizado com royalties sobre distribuição futura.
Adequado para desenvolvimento de jogos interativos, aplicações educacionais e conteúdo multimídia com estrutura de marcos.
Permite que editoras contratem desenvolvimento externo e mantenham controle sobre distribuição e royalties.
Formaliza contratos entre agência e cliente final para programas multimídia, com clareza sobre direitos e pagamentos.
Estrutura de acordo mestre com aditivos facilita múltiplos projetos sob um mesmo contrato base.
Pode ser adaptado para contratos de desenvolvimento de módulos ou extensões sob royalties de receita.
No Brasil, o direito autoral de software é protegido pela Lei de Software (Lei 9.609/1998) e pelo Código Civil. Este modelo é compatível com legislação brasileira. Royalties sobre receita devem cumprir com as obrigações fiscais do software (ISS, ICMS, se aplicável). Recomenda-se revisar com advogado local se valores forem significativos ou se houver disputas de propriedade intelectual.
Em Portugal, a propriedade intelectual de software é regulada pela Lei do Direito de Autor (Lei 63/1985) e legislação de propriedade industrial. Royalties são tributáveis como rendimento do autor/desenvolvedor. Este modelo é adaptável à legislação portuguesa, mas recomenda-se verificar obrigações de retenção na fonte e conformidade fiscal com a Autoridade Tributária e Aduaneira (AT) se valor for elevado.
| Caminho | Melhor para | Custo | Tempo |
|---|---|---|---|
| Use o modelo | Projetos pequenos, primeira vez trabalhando com um desenvolvedor, ambas as partes em jurisdição simples. | Gratuito (modelo) + tempo para preencher; 1–2 horas. | 2–4 horas para adaptar, preencher e assinar; pode ser feito em 1 dia. |
| Modelo + revisão jurídica | Projetos de médio valor (5 mil–50 mil), múltiplos marcos ou royalties complexos, jurisdições diferentes (Brasil + Portugal). | Modelo gratuito + 500–1500 por revisão jurídica. | 1–2 semanas (tempo do advogado + sua revisão dos comentários). |
| Redigido sob medida | Projetos de alto valor (>50 mil), exclusividade, propriedade intelectual sensível, negociação comercial complexa, litígio antecipado. | 2000–5000+ por contrato. | 3–6 semanas (redação, iterações, finalizações). |
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
