Software Development Agreement Portugal (Contrato de Desenvolvimento de Software)

O Contrato de Desenvolvimento de Software é o documento empresarial celebrado em Portugal ao abrigo de Código Civil artigo 1154.º.

O artigo 1154.º do Código Civil estabelece que pelo contrato de prestação de serviços uma das partes se obriga a proporcionar à outra certo resultado do seu trabalho intelectual ou manual, com ou sem retribuição. Os contratos de desenvolvimento de software qualificam-se tipicamente como prestação de serviços de resultado (não de meios), com o desenvolvedor a obrigar-se à entrega de um programa funcional cumprindo as especificações acordadas — distinguindo-se da empreitada regulada pelos artigos 1207.º e seguintes do Código Civil, embora a jurisprudência portuguesa admita aplicação subsidiária do regime da empreitada quando o programa apresente características de obra executada por adjudicação.

A titularidade originária dos direitos de autor sobre o software desenvolvido constitui o aspecto jurídico mais sensível. Pelo regime geral do artigo 11.º do CDADC, a obra encomendada pertence ao seu criador (o autor pessoa singular ou — quando a equipa do desenvolvedor seja constituída por trabalhadores — o próprio desenvolvedor), conferindo ao cliente apenas uma licença de uso para a finalidade implícita da encomenda. Esta regra é particularmente desfavorável ao cliente que pretenda explorar o software com a maior amplitude (modificação, sublicenciamento a terceiros, derivação para novos produtos). Por essa razão, o contrato deve regular expressamente a transmissão dos direitos patrimoniais para o cliente, distinguindo entre cessão total e definitiva (que requer escritura pública nos termos do artigo 41.º nº 2 do CDADC) e cessão parcial (que admite escrito particular nos termos do artigo 43.º nº 2).

O Decreto-Lei nº 252/94 introduz uma regra particular para programas de computador: o artigo 3.º nº 3 estabelece que pertencem ao empregador os programas criados por trabalhador no exercício das suas funções ou segundo as instruções da entidade patronal, salvo convenção em contrário. Esta regra resolve a titularidade na relação entre o desenvolvedor (sociedade) e os seus programadores assalariados, mas não resolve a relação entre o desenvolvedor e o cliente — para esta, é necessária cessão expressa que pode ser estipulada no próprio contrato de desenvolvimento. Os freelancers e prestadores autónomos contratados pelo desenvolvedor para participar no projecto exigem também regime contratual específico para garantir a cadeia de titularidade dos direitos.

O regime de execução contratual segue tipicamente metodologias de gestão de projecto reconhecidas internacionalmente. O modelo waterfall (cascata) define fases sequenciais — análise de requisitos, desenho, desenvolvimento, testes, implementação — com marcos de entrega e pagamento associados. O modelo agile (Scrum, Kanban) organiza o desenvolvimento em iterações curtas (sprints) com entregas incrementais e prioridades reajustáveis. Os contratos híbridos combinam elementos: marcos contratuais maiores no plano waterfall, com gestão operacional em sprints. Esta escolha metodológica determina a estrutura do contrato — descrição de requisitos versus product backlog evolutivo, pagamento por marcos versus pagamento por sprint, regime de aceitação por entrega versus aceitação por release.

A Inspecção-Geral das Actividades Culturais (IGAC) é o organismo público competente para o registo facultativo do software desenvolvido. Os efeitos práticos do Contrato de Desenvolvimento de Software em Portugal organizam-se em três planos: o contratual (responsabilidade civil sob os artigos 798.º e seguintes do Código Civil), o autoral (regime do CDADC e do Decreto-Lei nº 252/94, com competência do Tribunal da Propriedade Intelectual com sede em Lisboa criado pela Lei nº 46/2011 de 24 de Junho), e o laboral (presunção de subordinação do artigo 12.º do Código do Trabalho aprovado pela Lei nº 7/2009 quando o desenvolvedor seja pessoa singular com características de trabalhador). A intervenção da Autoridade para as Condições do Trabalho (ACT) é frequente em fiscalizações de "falsos recibos verdes" no sector tecnológico português.

O Contrato de Desenvolvimento de Software em Portugal é necessário sempre que uma empresa pretenda encomendar a um prestador externo a concepção, programação e entrega de um programa de computador à medida das suas necessidades, distinguindo-se do licenciamento de software pré-existente, da prestação de serviços de Software as a Service (SaaS) e da contratação laboral de programadores internos. A formalização escrita exigida pela aplicação subsidiária do artigo 41.º do Código do Direito de Autor e dos Direitos Conexos (CDADC, Decreto-Lei nº 63/85) é pressuposto da segurança jurídica, especialmente quanto à titularidade dos direitos sobre o resultado.

O desenvolvimento de plataformas digitais constitui o cenário típico. Empresas portuguesas que pretendem lançar plataformas de e-commerce, marketplaces, portais B2B, aplicações móveis (iOS, Android), sistemas de gestão interna, integrações com ERP corporativo ou soluções de business intelligence contratam regularmente desenvolvedores especializados — agências digitais, software houses, freelancers. O sector tecnológico português conta com clusters reconhecidos em Lisboa (com o Hub Criativo do Beato), Porto (UPTEC e ScaleUp Porto), Coimbra (Instituto Pedro Nunes), Aveiro (Universidade de Aveiro e parques tecnológicos) e Braga (Startup Braga), com forte presença internacional pós-Web Summit Lisboa.

Os projectos do Plano de Recuperação e Resiliência (PRR) com financiamento europeu impulsionaram significativamente a contratação de desenvolvimento de software pela Administração Pública e por empresas privadas que executam projectos co-financiados. As regras de elegibilidade do PRR e do Portugal 2030 exigem documentação contratual robusta, com especificação detalhada de entregáveis, regime de aceitação e titularidade dos direitos de propriedade intelectual sobre o resultado. A Agência para o Desenvolvimento e Coesão (AD&C) e o IAPMEI — Agência para a Competitividade e Inovação realizam fiscalizações periódicas que verificam a conformidade da execução contratual com as exigências do financiamento.

O desenvolvimento de software para a saúde é cenário particularmente sensível. Os sistemas de informação hospitalar, plataformas de telemedicina, aplicações de saúde móvel (mHealth), software de dispositivo médico ao abrigo do Regulamento (UE) 2017/745 e do Regulamento (UE) 2017/746 exigem conformidade com normas técnicas (ISO 14971 para gestão de risco, IEC 62304 para ciclo de vida de software médico, IEC 82304 para software autónomo) e regulamentos sectoriais (RGPD com regras particulares para dados de saúde, regulamentação INFARMED, normas SPMS). O contrato deve prever obrigação do desenvolvedor de cumprir estes requisitos e suportar custos de eventual recertificação por alterações regulatórias.

No sector financeiro, o desenvolvimento de software para bancos, sociedades financeiras, fintechs e seguradoras está sujeito a regime particular de supervisão. O Banco de Portugal (BdP), a Comissão do Mercado de Valores Mobiliários (CMVM) e a Autoridade de Supervisão de Seguros e Fundos de Pensões (ASF) exigem conformidade com regulamentos específicos — Aviso 3/2020 do BdP sobre subcontratação de serviços relevantes, regulamento europeu DORA (Digital Operational Resilience Act) sobre resiliência operacional digital, normas técnicas EBA sobre arrangements de outsourcing. O contrato deve prever auditoria pelo regulador, planos de contingência, e regime de transição em caso de cessação.

Nas startups inscritas na Startup Portugal e nos programas da IAPMEI, o desenvolvimento de software constitui frequentemente o core do produto e do valor da empresa. As rondas de investimento por sociedades de capital de risco registadas na CMVM exigem mapeamento completo da titularidade dos direitos de propriedade intelectual sobre o software, incluindo verificação dos contratos com os desenvolvedores externos e com os colaboradores internos. A descoberta de cessões em falta ou ambíguas pode resultar em ajustes de valoração ou retenção de parte do investimento até regularização.

Nas operações de aquisição de empresas com componente tecnológica relevante, a análise dos contratos de desenvolvimento de software é elemento essencial da due diligence tecnológica. Verificações típicas incluem: titularidade efectiva dos direitos pelo target (cessão completa pelos desenvolvedores externos, presunção do artigo 3.º nº 3 do Decreto-Lei nº 252/94 para colaboradores internos), inexistência de obrigações copyleft por incorporação descontrolada de componentes open source, conformidade com regime de protecção de dados, existência de documentação técnica suficiente para manutenção autónoma. As deficiências detectadas podem motivar pedidos de garantia adicional pelo adquirente, ajustes de preço ou retenção de parte do valor da operação.

Um Contrato de Desenvolvimento de Software em Portugal juridicamente eficaz integra um conjunto de cláusulas técnicas indispensáveis à executoriedade perante o Tribunal da Propriedade Intelectual com sede em Lisboa e à protecção do investimento de ambas as partes, conforme exigido pela articulação entre o artigo 1154.º do Código Civil (prestação de serviços), o Decreto-Lei nº 252/94 (programas de computador) e o Código do Direito de Autor e dos Direitos Conexos (CDADC, Decreto-Lei nº 63/85).

Identificação rigorosa das partes — primeiro elemento. Para o desenvolvedor, devem constar nome ou denominação social, número de identificação fiscal (NIF) ou número de identificação de pessoa colectiva (NIPC), domicílio fiscal ou sede social, e qualidade em que age (sociedade comercial portuguesa, sucursal de sociedade estrangeira, freelancer trabalhador independente). Para o cliente, exige-se identificação completa idêntica. Para sociedades comerciais, a certidão permanente actualizada na Conservatória do Registo Comercial confirma a designação social, NIPC, sede e poderes de representação.

Descrição do projecto — segundo elemento estruturante. Em projectos waterfall, a descrição assume a forma de Especificações Técnicas e Funcionais detalhadas, com requisitos funcionais (funcionalidades a implementar), requisitos não funcionais (performance, escalabilidade, segurança), arquitectura técnica de referência, integrações com sistemas existentes, e critérios de aceitação objectivos. Em projectos agile, a descrição assume a forma de Product Backlog inicial e definição de Definition of Done, com mecanismo contratual para evolução do escopo (change requests). Em projectos híbridos, combinam-se ambas as estruturas. Anexos técnicos detalhados são incorporados ao contrato e integram-no para todos os efeitos.

Metodologia, prazos e marcos — terceiro elemento crítico. A cláusula deve fixar (i) a metodologia adoptada (waterfall, agile Scrum, Kanban, híbrido); (ii) o cronograma com marcos de entrega; (iii) os entregáveis associados a cada marco; (iv) os prazos com data de início e data de termo; (v) o regime de prorrogação de prazos e de gestão de impedimentos imputáveis ao cliente. Em metodologias agile, devem definir-se a duração dos sprints (tipicamente 2 semanas), os papéis (Product Owner do cliente, Scrum Master e equipa do desenvolvedor) e os rituais (planning, daily, review, retrospective).

Regime de aceitação. A cláusula deve fixar (i) o procedimento de testes de aceitação (User Acceptance Tests, UAT); (ii) o prazo do cliente para realizar os testes (tipicamente 10 a 30 dias úteis após entrega); (iii) o regime de aceitação tácita por silêncio do cliente; (iv) a classificação de defeitos por severidade (críticos bloqueantes da aceitação, maiores corrigíveis no prazo combinado, menores reportáveis para correcção em release subsequente); (v) o regime de correcção pelo desenvolvedor; (vi) o efeito jurídico da aceitação na transmissão de riscos e no início da garantia.

Titularidade dos direitos de propriedade intelectual — elemento central. O contrato deve regular expressamente a titularidade dos direitos sobre: (i) o software desenvolvido especificamente para o cliente, com cessão dos direitos patrimoniais ao cliente nos termos do artigo 44.º do CDADC; (ii) bibliotecas, frameworks e componentes pré-existentes do desenvolvedor, sob licença ao cliente para utilização integrada no software desenvolvido; (iii) componentes open source incorporados, com indicação das licenças aplicáveis e respeito pelas obrigações; (iv) ferramentas e metodologias do desenvolvedor que continuem na sua esfera; (v) materiais e dados fornecidos pelo cliente. Para cessão total e definitiva, o artigo 41.º nº 2 do CDADC exige escritura pública — frequentemente acompanhada por documento particular autenticado nos termos do Decreto-Lei nº 116/2008 quando lavrado por advogado.

Contrapartida e modos de pagamento. As estruturas mais comuns incluem (a) preço fixo (fixed price) para projectos waterfall com escopo bem definido; (b) preço por marco (milestone payments) com pagamentos associados às entregas validadas; (c) preço por tempo e materiais (time and materials, T&M) com facturação por horas trabalhadas e tarifas diárias acordadas; (d) preço por sprint (capacity-based) em metodologias agile com equipa dedicada. Devem prever-se condições de pagamento (data de vencimento, forma de pagamento, juros de mora nos termos do artigo 102.º do Código Comercial), retenção sobre pagamentos finais (typically 10% retidos até verificação final), e regime de IVA à taxa normal de 23% nos termos do artigo 18.º do Código do IVA.

Garantia técnica. A cláusula deve fixar (i) o prazo de garantia (tipicamente 6 a 24 meses após aceitação); (ii) o âmbito da garantia (correcção de defeitos não detectados durante UAT); (iii) os tempos de resposta por severidade do defeito; (iv) os limites da garantia (não cobre alterações de escopo, modificações pelo cliente, factores externos); (v) o regime de manutenção evolutiva pós-garantia (objecto de contrato adicional ou pacote de horas).

Confidencialidade e protecção de dados. O contrato deve incluir cláusula de confidencialidade vinculando o desenvolvedor ao sigilo da informação do cliente e — quando aplicável — anexar contrato de subcontratação ao abrigo do artigo 28.º do RGPD para tratamento de dados pessoais durante o desenvolvimento e os testes. A Comissão Nacional de Protecção de Dados (CNPD) pode aplicar coimas até 20 milhões de euros ou 4% do volume de negócios anual mundial nos termos do artigo 83.º do RGPD.

Lei aplicável e foro. O contrato deve declarar a lei portuguesa como lei reguladora ao abrigo do artigo 3.º do Regulamento (CE) 593/2008 (Roma I). Para questões relativas à titularidade dos direitos sobre o software, a competência exclusiva pertence ao Tribunal da Propriedade Intelectual em Lisboa nos termos da Lei nº 46/2011. Para questões puramente contratuais (incumprimento de prazos, defeitos, pagamentos), aplica-se a competência geral do Juízo de Comércio.

A forms-legal.com disponibiliza este modelo de Contrato de Desenvolvimento de Software em Portugal como ponto de partida operacional, devendo a redação final ser revista por advogado inscrito na Ordem dos Advogados especializado em direito tecnológico. Documentos relacionados disponíveis no nosso catálogo: o Contrato de Licença de Software (para regulação do uso de software pré-existente) e o Acordo de Confidencialidade Empresarial (para a fase pré-contratual).

O preenchimento do Contrato de Desenvolvimento de Software em Portugal segue uma sequência prática que assegura conformidade com o artigo 1154.º do Código Civil, com o Decreto-Lei nº 252/94 e com o Código do Direito de Autor e dos Direitos Conexos (CDADC, Decreto-Lei nº 63/85). A ordem recomendada começa pela definição clara do escopo e da metodologia.

Primeiro passo: qualificar a natureza do projecto. Determine se se trata de desenvolvimento de plataforma autónoma, de aplicação móvel, de integração com sistemas existentes, de software embebido em equipamento, ou de evolução de produto pré-existente. Esta qualificação determina a estrutura do contrato, o regime de aceitação e a complexidade dos anexos técnicos. Para desenvolvimento sujeito a regulamentação sectorial (saúde, financeiro, dispositivos médicos), confirme os requisitos regulatórios aplicáveis e a obrigação do desenvolvedor de os cumprir.

Segundo passo: identificar com precisão as partes. Para sociedades comerciais portuguesas, obtenha a certidão permanente actualizada na Conservatória do Registo Comercial (acesso em www.empresaonline.pt) e confirme a designação social, NIPC, sede, capital social e poderes de representação dos signatários. Para freelancers, recolha NIF, certidão de actividade da AT — Autoridade Tributária e Aduaneira, e — quando aplicável — número de inscrição em ordem profissional. Para desenvolvedores estrangeiros, confirme a identificação fiscal e considere a aplicação de retenção na fonte de IRC sobre pagamentos ao exterior nos termos do artigo 94.º do CIRC.

Terceiro passo: definir o escopo. Em projectos waterfall, anexe Especificações Técnicas e Funcionais detalhadas com: requisitos funcionais (funcionalidades a implementar, fluxos de utilizador), requisitos não funcionais (performance, escalabilidade, segurança, compatibilidade), arquitectura técnica de referência, integrações com sistemas existentes, e critérios de aceitação objectivos. Em projectos agile, anexe Product Backlog inicial com user stories priorizadas e Definition of Done. Em projectos híbridos, combine ambas as estruturas. Inclua mecanismo contratual para evolução do escopo (change requests com avaliação de impacto em prazo e preço).

Quarto passo: definir metodologia e prazos. Indique a metodologia adoptada (waterfall, agile Scrum, Kanban, híbrido). Em waterfall, defina o cronograma com marcos de entrega, entregáveis associados a cada marco, e prazos com data de início e termo. Em agile, defina a duração dos sprints (tipicamente 2 semanas), os papéis (Product Owner do cliente, Scrum Master e equipa do desenvolvedor), os rituais (planning, daily, review, retrospective) e o número estimado de sprints. Em qualquer caso, defina o regime de prorrogação de prazos e de gestão de impedimentos imputáveis ao cliente (atrasos de aprovação, alterações de escopo, indisponibilidade de informação).

Quinto passo: regime de aceitação. Defina o procedimento de testes de aceitação (User Acceptance Tests, UAT), o prazo do cliente para realizar os testes (tipicamente 10 a 30 dias úteis após entrega), o regime de aceitação tácita por silêncio do cliente após o prazo, a classificação de defeitos por severidade (críticos bloqueantes da aceitação, maiores corrigíveis em prazo combinado, menores reportáveis para correcção em release subsequente), o regime de correcção pelo desenvolvedor, e o efeito jurídico da aceitação na transmissão de riscos e no início da garantia.

Sexto passo: titularidade dos direitos de propriedade intelectual. Regule expressamente a titularidade dos direitos sobre: (i) o software desenvolvido especificamente — com cessão dos direitos patrimoniais ao cliente nos termos do artigo 44.º do CDADC; (ii) bibliotecas e componentes pré-existentes do desenvolvedor — com licença ao cliente para utilização integrada; (iii) componentes open source incorporados — com inventário (Software Bill of Materials, SBOM) e indicação das licenças aplicáveis; (iv) ferramentas e metodologias do desenvolvedor; (v) materiais e dados fornecidos pelo cliente. Para cessão total e definitiva, considere a celebração de escritura pública nos termos do artigo 41.º nº 2 do CDADC ou de documento particular autenticado por advogado nos termos do Decreto-Lei nº 116/2008.

Sétimo passo: estruturar a contrapartida. Decida o modelo de pagamento — preço fixo (fixed price), preço por marco (milestone payments), preço por tempo e materiais (T&M), preço por sprint. Estabeleça as condições de pagamento (data de vencimento, forma de pagamento, juros de mora à taxa legal em vigor para créditos comerciais), retenção sobre pagamentos finais (tipicamente 10% retidos até verificação final), e o regime de IVA à taxa normal de 23% nos termos do artigo 18.º do Código do IVA. Para pagamentos a desenvolvedores não residentes, considere a retenção na fonte de IRC nos termos do artigo 94.º do CIRC.

Oitavo passo: garantia técnica. Fixe o prazo de garantia (tipicamente 6 a 24 meses após aceitação), o âmbito da garantia (correcção de defeitos não detectados durante UAT), os tempos de resposta por severidade do defeito, os limites da garantia (não cobre alterações de escopo, modificações pelo cliente, factores externos), e o regime de manutenção evolutiva pós-garantia (objecto de contrato adicional ou pacote de horas).

Nono passo: confidencialidade e protecção de dados. Inclua cláusula de confidencialidade vinculando o desenvolvedor ao sigilo da informação do cliente, com indicação clara das categorias de informação confidencial. Quando o desenvolvimento implique tratamento de dados pessoais (incluindo dados de teste em ambientes de desenvolvimento), anexe contrato de subcontratação ao abrigo do artigo 28.º do RGPD com indicação clara de finalidades, durações, tipos de dados, categorias de titulares e medidas técnicas e organizativas. Identifique o encarregado de protecção de dados (DPO) quando aplicável.

Décimo passo: assinatura. O contrato exige forma escrita por aplicação subsidiária do artigo 41.º do CDADC. Para reforço probatório, recomenda-se reconhecimento presencial das assinaturas em cartório notarial, balcão da Conservatória ou perante advogado nos termos do artigo 38.º do Decreto-Lei nº 76-A/2006, ou assinatura electrónica qualificada com Cartão de Cidadão ou Chave Móvel Digital ao abrigo do Regulamento (UE) 910/2014 (eIDAS) e do Decreto-Lei nº 12/2021. Para cessão total dos direitos de autor, considere a celebração separada de escritura pública nos termos do artigo 41.º nº 2 do CDADC. Conserve cópias datadas em arquivo seguro durante o prazo do contrato e o período de prescrição (20 anos para responsabilidade contratual nos termos do artigo 309.º do Código Civil).

Os requisitos legais do Contrato de Desenvolvimento de Software em Portugal resultam da articulação entre o regime do Código Civil de 1966 (artigos 1154.º a 1156.º para prestação de serviços), o Decreto-Lei nº 252/94 de 20 de Outubro relativo aos programas de computador, o Código do Direito de Autor e dos Direitos Conexos (CDADC, Decreto-Lei nº 63/85), e regimes complementares de natureza laboral, fiscal e de protecção de dados.

Qualificação contratual. O artigo 1154.º do Código Civil define o contrato de prestação de serviços como aquele pelo qual uma das partes se obriga a proporcionar à outra certo resultado do seu trabalho intelectual ou manual, com ou sem retribuição. Quando o resultado seja um programa de computador, aplica-se subsidiariamente o regime da empreitada nos termos do artigo 1156.º do Código Civil em tudo o que não esteja regulado especificamente. A qualificação como prestação de serviços, e não como contrato de trabalho, é essencial para evitar a aplicação do regime laboral do Código do Trabalho aprovado pela Lei nº 7/2009 — em particular o artigo 12.º que estabelece a presunção de subordinação quando estejam presentes múltiplos indicadores (local, horário, instrumentos de trabalho, integração na estrutura, exclusividade). A Autoridade para as Condições do Trabalho (ACT) tem fiscalizado intensamente o sector tecnológico português contra os "falsos recibos verdes".

Forma. O contrato de prestação de serviços não exige forma específica, sendo válida a forma livre nos termos do artigo 219.º do Código Civil. Contudo, o artigo 41.º do CDADC, aplicável às cláusulas de transmissão dos direitos de autor sobre o software desenvolvido, exige forma escrita sob pena de nulidade. Para a cessão total e definitiva dos direitos patrimoniais, o artigo 41.º nº 2 exige escritura pública ou documento particular autenticado nos termos do Decreto-Lei nº 116/2008. Para cessão parcial (apenas algumas faculdades, prazo limitado, território limitado), basta o escrito particular nos termos do artigo 43.º nº 2.

Capacidade e legitimidade. As partes devem ter capacidade jurídica para contratar nos termos dos artigos 67.º a 130.º do Código Civil. Para pessoas colectivas, a vinculação faz-se nos termos dos artigos 252.º e 405.º do Código das Sociedades Comerciais consoante se trate de Sociedade por Quotas ou Sociedade Anónima. Para freelancers pessoas singulares, é essencial a qualidade de trabalhador independente devidamente registada na AT — Autoridade Tributária e Aduaneira e na Segurança Social, evitando a configuração de relação laboral encapotada.

Regime dos direitos de autor sobre o software desenvolvido. O artigo 11.º do CDADC presume que a obra encomendada pertence ao seu criador, conferindo ao encomendante apenas uma licença de uso para a finalidade implícita da encomenda. Esta regra geral é particularmente desfavorável ao cliente. O artigo 3.º nº 3 do Decreto-Lei nº 252/94 estabelece regime particular para programas de computador, atribuindo a titularidade ao empregador quando o programa seja criado por trabalhador no exercício das suas funções — regra que se aplica entre o desenvolvedor e os seus programadores assalariados, mas não automaticamente entre o desenvolvedor e o cliente. Esta resolução exige cessão expressa no contrato.

Direitos morais. Os artigos 56.º a 62.º do CDADC qualificam os direitos morais como inalienáveis, irrenunciáveis e imprescritíveis. Mesmo após cessão completa dos direitos patrimoniais sobre o software desenvolvido, os autores pessoas singulares (designadamente os programadores que efectivamente escreveram o código) conservam o direito à paternidade da obra. Esta característica é especialmente relevante para software open source desenvolvido para o cliente, em que os autores podem reclamar atribuição em ficheiros de copyright e licenças.

Garantia legal. Aplica-se subsidiariamente o regime da empreitada quanto à garantia por defeitos. O artigo 1218.º do Código Civil estabelece a obrigação de eliminação dos defeitos pelo empreiteiro. Os artigos 1219.º a 1225.º regulam as modalidades alternativas (reparação, redução do preço, resolução do contrato) e os prazos de denúncia (30 dias da descoberta) e caducidade (1 ano para imóveis, 6 meses para móveis a contar da entrega — embora a doutrina sustente prazos mais longos para programas complexos). O contrato pode estipular regime mais favorável ao cliente, mas não pode reduzir as garantias mínimas do regime imperativo, especialmente quando o cliente seja consumidor nos termos da Lei nº 24/96 e do Decreto-Lei nº 84/2021 (transposição da Directiva (UE) 2019/770 sobre fornecimento de conteúdos e serviços digitais).

Responsabilidade civil. A responsabilidade do desenvolvedor por incumprimento contratual segue os artigos 798.º a 812.º do Código Civil. Pode estipular-se cláusula penal nos termos dos artigos 810.º a 812.º para liquidação prévia da indemnização, sujeita a redução equitativa pelo tribunal nos termos do artigo 812.º quando manifestamente excessiva. Pode estipular-se igualmente limitação da responsabilidade quanto a danos indirectos e quanto a montante máximo, válida entre profissionais mas potencialmente inoponível quando o cliente seja consumidor ou quando a limitação seja abusiva nos termos do regime das cláusulas contratuais gerais do Decreto-Lei nº 446/85.

Regime fiscal. Os pagamentos pelo serviço de desenvolvimento estão sujeitos a IVA à taxa normal de 23% nos termos do artigo 18.º do Código do IVA. Para o desenvolvedor pessoa singular trabalhador independente, os rendimentos qualificam-se como categoria B do IRS nos termos do artigo 3.º do Código do IRS, com retenção na fonte de 25% para serviços de natureza profissional nos termos do artigo 101.º do CIRS quando o pagador tenha contabilidade organizada. Para a sociedade desenvolvedora, os rendimentos integram o lucro tributável em sede de IRC à taxa de 21% nos termos do artigo 87.º do CIRC, mais derrama municipal e estadual. As sociedades qualificáveis como PME beneficiam da taxa reduzida de 17% sobre os primeiros 50.000 euros de matéria colectável. Aplicam-se ainda os benefícios fiscais ao investimento em I&D ao abrigo do SIFIDE — Sistema de Incentivos Fiscais à Investigação e Desenvolvimento Empresarial.

Protecção de dados. Quando o desenvolvimento implique tratamento de dados pessoais (incluindo dados reais ou dados de teste em ambientes de desenvolvimento), aplicam-se o Regulamento (UE) 2016/679 (RGPD) e a Lei nº 58/2019 de 8 de Agosto. É exigido contrato de subcontratação ao abrigo do artigo 28.º do RGPD. As medidas técnicas e organizativas devem cumprir o artigo 32.º. A Comissão Nacional de Protecção de Dados (CNPD) pode aplicar coimas até 20 milhões de euros ou 4% do volume de negócios anual mundial nos termos do artigo 83.º do RGPD.

Os erros mais frequentes na celebração do Contrato de Desenvolvimento de Software em Portugal podem expor o cliente ao risco de não obter a titularidade dos direitos sobre o resultado, e o desenvolvedor ao risco de qualificação como contrato de trabalho com consequências fiscais e laborais.

Descrição vaga do escopo do projecto. A cláusula tipo "desenvolvimento de plataforma de e-commerce" sem Especificações Técnicas e Funcionais detalhadas, sem requisitos não funcionais e sem critérios de aceitação objectivos gera litígios sobre a conformidade do entregável com as expectativas do cliente. A jurisprudência do Tribunal de Comarca tem decidido pela aplicação de critérios médios de mercado quando o contrato seja silencioso, frequentemente desfavoráveis para o cliente que esperava funcionalidades específicas. A solução é anexar Especificações Técnicas e Funcionais detalhadas em projectos waterfall, ou Product Backlog inicial e Definition of Done em projectos agile, com mecanismo contratual claro para evolução do escopo (change requests com avaliação de impacto em prazo e preço).

Falta de cláusula expressa sobre titularidade dos direitos de autor. Quando o contrato é silencioso, aplica-se o regime supletivo do artigo 11.º do Código do Direito de Autor e dos Direitos Conexos (CDADC, Decreto-Lei nº 63/85): a obra encomendada pertence ao seu criador, conferindo ao cliente apenas uma licença de uso para a finalidade implícita da encomenda. O cliente pode encontrar-se sem titularidade dos direitos sobre o software pago, sem possibilidade de modificá-lo, sublicenciá-lo ou comercializá-lo autonomamente. A solução é incluir cláusula expressa de cessão dos direitos patrimoniais ao cliente nos termos do artigo 44.º do CDADC, e — para cessão total e definitiva — formalizar a cessão em escritura pública ou documento particular autenticado nos termos do artigo 41.º nº 2.

Qualificação errada como contrato de trabalho. Quando o desenvolvedor seja pessoa singular freelancer e o contrato apresente características de subordinação (local fixo de trabalho nas instalações do cliente, horário definido pelo cliente, instrumentos de trabalho fornecidos pelo cliente, integração na estrutura organizativa, exclusividade de facto), aplica-se a presunção de subordinação do artigo 12.º do Código do Trabalho aprovado pela Lei nº 7/2009. A Autoridade para as Condições do Trabalho (ACT) pode requalificar a relação como contrato de trabalho, com consequências fiscais (TSU patronal de 23,75% e contribuição do trabalhador de 11%) e laborais (subsídios de férias e Natal, indemnização por cessação). A solução é estruturar a relação genuinamente como prestação de serviços — o desenvolvedor trabalha autonomamente, com os seus próprios instrumentos, define livremente o seu horário, presta serviços a múltiplos clientes — e documentá-lo no contrato.

Omissão da gestão de componentes open source. Sem inventário (Software Bill of Materials, SBOM) e classificação das licenças open source incorporadas, o cliente pode encontrar-se com obrigações copyleft (GPL, LGPL, AGPL) que o obriguem a libertar o código-fonte do produto comercial ao público, com impacto significativo no modelo de negócio. A solução é incluir cláusula expressa exigindo ao desenvolvedor a entrega de SBOM completo, classificação das licenças quanto a obrigações copyleft, e — quando se pretenda manter código proprietário — utilização exclusiva de componentes sob licenças permissivas (MIT, BSD, Apache).

Falta de regime de aceitação claro. Sem procedimento detalhado de testes de aceitação (User Acceptance Tests, UAT), prazo do cliente para realizar testes, regime de aceitação tácita por silêncio, classificação de defeitos por severidade e regime de correcção, surgem disputas prolongadas sobre o cumprimento contratual. A solução é definir expressamente o procedimento de UAT, o prazo (tipicamente 10 a 30 dias úteis), o regime de aceitação tácita após o prazo, a classificação de defeitos (críticos, maiores, menores) e o regime de correcção pelo desenvolvedor com prazos por severidade.

Ausência de cláusula de garantia técnica clara. Sem regulação contratual da garantia, surge incerteza sobre o prazo, o âmbito e os tempos de resposta. A solução é fixar prazo de garantia (tipicamente 6 a 24 meses após aceitação), âmbito (correcção de defeitos não detectados durante UAT), tempos de resposta por severidade, limites (não cobre alterações de escopo, modificações pelo cliente, factores externos) e regime de manutenção evolutiva pós-garantia (objecto de contrato adicional).

Falta de regulação dos materiais pré-existentes do desenvolvedor. Quando o desenvolvedor incorpora no software entregue componentes, bibliotecas ou frameworks que desenvolveu anteriormente para outros clientes ou para uso geral, surge incerteza sobre a titularidade. A solução é incluir cláusula expressa que distinga: (i) software desenvolvido especificamente para o cliente (cessão dos direitos ao cliente); (ii) componentes pré-existentes do desenvolvedor (licença ao cliente para utilização integrada, com possibilidade de o desenvolvedor continuar a utilizá-los noutros projectos); (iii) materiais e dados fornecidos pelo cliente (titularidade conservada pelo cliente).

Omissão das cláusulas sobre dados pessoais. Quando o desenvolvimento implique tratamento de dados pessoais — incluindo dados reais em ambientes de produção, ou dados de teste em ambientes de desenvolvimento — a ausência de contrato de subcontratação ao abrigo do artigo 28.º do RGPD expõe ambas as partes a coimas administrativas até 20 milhões de euros ou 4% do volume de negócios anual mundial nos termos do artigo 83.º do RGPD. A solução é anexar contrato de subcontratação cumprindo os requisitos do artigo 28.º, com prática de pseudonimização ou anonimização dos dados utilizados em ambientes de desenvolvimento sempre que tecnicamente viável.