“Demandas legais no desenvolvimento de software sob uma visão
tecnológica”, de Claudio F Filho, foi licenciada com uma Licença Creative
Commons Atribuição - Uso não-comercial - Compartilhamento pela mesma
licença 3.0 Não adaptada.
http://creativecommons.org/licenses/by-nc-sa/3.0/br/
Você tem a liberdade de:
•
Compartilhar — copiar, distribuir e transmitir a obra.
•
Remixar — criar obras derivadas.
Sob as seguintes condições:
•
Atribuição — Você deve creditar a obra da forma especificada pelo autor ou licenciante
(mas não de maneira que sugira que estes concedem qualquer aval a você ou ao seu
uso da obra).
•
Uso não-comercial — Você não pode usar esta obra para fins comerciais.
•
Compartilhamento pela mesma licença — Se você alterar, transformar ou criar em cima
desta obra, você poderá distribuir a obra resultante apenas sob a mesma licença, ou
sob uma licença similar à presente.
Ficando claro que:
•
Renúncia — Qualquer das condições acima pode ser renunciada se você obtiver
permissão do titular dos direitos autorais.
•
Domínio Público — Onde a obra ou qualquer de seus elementos estiver em domínio
público sob o direito aplicável, esta condição não é, de maneira alguma, afetada pela
licença.
•
Outros Direitos — Os seguintes direitos não são, de maneira alguma, afetados pela
licença:
◦
Limitações e exceções aos direitos autorais ou quaisquer usos livres aplicáveis;
◦
Os direitos morais do autor;
◦
Direitos que outras pessoas podem ter sobre a obra ou sobre a utilização da obra,
tais como direitos de imagem ou privacidade.
Aviso — Para qualquer reutilização ou distribuição, você deve deixar claro a terceiros os termos
da licença a que se encontra submetida esta obra. A melhor maneira de fazer isso é com um
link para esta página.
Agradecimentos
Agradeço a estas pessoas pelo desenvolvimento deste trabalho, com
colaborações desde sugestões, críticas e correções:
Claudia Ferreira
Érico Ferreira
Leonardo Cezar
Marcelo Moura
Marco Scheiner
Meg Mendonça
Reinaldo Vale
Contatos
E-mail:
[email protected]
Identi.ca:
http://identi.ca/filhocf
Twitter:
http://twitter.com/filhocf
Histórico do documento
Data
Versão
Autor
16/01/12
0.1
Claudio F Filho
Versão inicial.
24/01/12
0.2
Claudio F Filho
Adição das seções “Novos modelos de negócio”,
“Relações trabalhistas” e “Outras considerações”.
02/02/12
0.3
Claudio F Filho
Adição de várias considerações e melhorias no texto a
partir de sugestões de Marcelo Moura e Meg Mendonça,
adição de responsabilidades no desenvolvimento e
desenvolvimento para órgãos públicos.
09/02/12
0.4
Claudio F Filho
Adição das questões relacionadas a marca, evolução do
desenho de inter-relação das licenças, adição da
definição de cloud computing, adição da MPL 2.0, e
virtualização.
26/02/12
0.5
Claudio F Filho
Adição das figuras elaboradas para o infográfico e
apresentação deste material, nota legal, resumo e
material complementar.
3 de 69
Alteração
Aspectos legais no desenvolvimento de soluções de TI
Índice
0.Aviso legal................................................................................................................................ 6
1.Introdução................................................................................................................................ 7
2.Definições................................................................................................................................. 9
2.1.Computação em nuvem (Cloud Computing)......................................................................9
2.2.Engenharia reversa........................................................................................................... 9
2.3.Framework...................................................................................................................... 10
2.4.Infraestrutura.................................................................................................................. 10
2.4.1.Infraestrutura de desenvolvimento..........................................................................11
2.4.2.Infraestrutura de hospedagem.................................................................................11
2.5.Licença............................................................................................................................ 12
2.5.1.Licença de software.................................................................................................14
2.5.2.Licença Pública de Marca......................................................................................... 15
2.6.Marca.............................................................................................................................. 15
2.7.Programa de computador (ou software)..........................................................................16
2.8.Registro de programas de computadores........................................................................16
2.9.Tecnologia....................................................................................................................... 17
2.10.Virtualização.................................................................................................................. 17
3.Breve classificação de software..............................................................................................19
3.1.Licenças fechadas........................................................................................................... 20
3.1.1.Adware..................................................................................................................... 20
3.1.2.Freeware ou Gratuito............................................................................................... 20
3.1.3.Instalado em um computador ou OEM.....................................................................21
3.1.4.Por volume ou integrador........................................................................................21
3.1.5.Software como Serviço (SaaS).................................................................................22
3.1.6.Shareware (ou Trial)................................................................................................22
3.1.7.Licenciamento Único, de Caixa ou FPP (Full Packaged Product)...............................23
3.2.Estudos de casos para licenças fechadas........................................................................23
3.3.Software proprietário vs Software privativo....................................................................25
3.4.Licenças compartilhadas................................................................................................. 25
3.5.Licenças abertas............................................................................................................. 26
3.5.1.Software livre........................................................................................................... 26
3.5.1.1.Protecionistas Totais.........................................................................................27
3.5.1.2.Protetivas Parciais............................................................................................ 29
3.5.2.Software público...................................................................................................... 32
3.5.3.Código aberto.......................................................................................................... 32
3.5.4.Domínio público....................................................................................................... 34
3.6.Novos modelos de negócios com licenças abertas..........................................................35
3.6.1.Subscrição de suporte..............................................................................................35
3.6.2.Contrato de instalação, configuração e suporte.......................................................35
3.6.3.Estratégia de bilicenciamento..................................................................................36
3.6.4.Segmentação em comunitário e empresarial...........................................................36
3.6.5.Comercialização de produtos abertos - permissivos................................................37
4.Análise dos pontos legais no desenvolvimento.......................................................................38
4.1.Cenário tecnológico......................................................................................................... 40
4.2.Início dos trabalhos......................................................................................................... 42
4.3.Requisitos........................................................................................................................ 44
4.4.Desenvolvimento............................................................................................................ 45
4.4.1.Ambientes................................................................................................................ 46
4.4.2.Elementos externos................................................................................................. 47
4.4.2.1.Bibliotecas........................................................................................................ 47
4 de 69
Aspectos legais no desenvolvimento de soluções de TI
4.4.2.2.Framework....................................................................................................... 49
4.4.2.3.Documentação.................................................................................................49
4.4.2.4.Sons, vídeos e imagens....................................................................................51
4.4.3.Declaração da licença.............................................................................................. 51
4.5.Registro........................................................................................................................... 54
4.6.Relações trabalhistas...................................................................................................... 54
5.Outras considerações............................................................................................................. 57
5.1.Licenças estrangeiras e a legislação brasileira................................................................57
5.2.Compatibilidade de licenças............................................................................................ 58
5.3.Responsabilidades dentro do desenvolvimento de software...........................................61
5.4.Software para órgãos públicos – aquisição e desenvolvimento.......................................64
5.5.A marca........................................................................................................................... 66
5.6.Fluxograma operacional de análise legal para desenvolvimento....................................67
6.Material complementar........................................................................................................... 69
6.1.Filmes.............................................................................................................................. 69
6.1.1.Piratas do Vale do Silício (1999)...............................................................................69
6.1.2.Revolution OS (2001)............................................................................................... 69
5 de 69
Aspectos legais no desenvolvimento de soluções de TI
0. Aviso legal
•
Eu não sou um advogado!
•
Nada que eu digo neste
aconselhamento jurídico;
•
Se você tem dúvidas com ramificações legais, entre em contato com
um advogado;
•
Falamos de bases legais diferentes, anglo-americanas e romanogermânicas. É necessário observar questões internacionais e tratados
sobre o assunto as quais o Brasil é signatário;
•
O material apresentado aqui foi compilado a partir de uma interpretação
coloquial do material disponível na internet, podendo ser acessado e
interpretado pelo leitor;
•
Todas as marcas aqui apresentadas são propriedade exclusiva de seus
respectivos proprietários;
•
Muitas figuras aqui apresentadas foram obtidas a partir do projeto
OpenClipart.org, licenciadas sob Domínio Público, outras foram
criadas por Claudio F Filho, bem como suas composições;
•
“Demandas Legais no Desenvolvimento de Software - sob uma visão
tecnológica” e suas figuras são licenciadas sob uma licença não portada
Creative Commons Atribuição - Uso não-comercial – Compartilhada pela
mesma licença 3.0 Não adaptada
trabalho
deve
ser
interpretada
como
.
6 de 69
Aspectos legais no desenvolvimento de soluções de TI
1. Introdução
O conceito de “Soluções de Tecnologia da Informação e Comunicação” - TIC – é
extremamente vago para os diversos participantes de um projeto de TIC, e
mais complicado ainda quando se começa uma análise dos pontos legais
incidentes sobre a parte técnica de um projeto em si.
O objetivo deste trabalho é mostrar os diversos aspectos legais envolvidos
nestes projetos, avaliando desde o processo de venda da solução, o impacto da
definição do cenário tecnológico, desenvolvimento de código, implantação da
solução, além da parte de licenciamento e registro do software, dos esquemas
de dados, dos dados em si e/ou da combinação de todos estes. Esta análise se
dá de forma genérica, buscando englobar características tanto da iniciativa
pública quanto privada, se tornando uma referência de comparação para
qualquer entidade. Porém, esta não é uma interpretação formal, uma vez que
foi feita por mim, um profissional da área de TIC, buscando unir visões sobre
várias partes do processo, licenciamento e questões legais.
Para chegar neste ponto é necessário fazer a uniformização de uma série de
termos e conceitos, de forma gradual, conforme aprofundamos nestas
questões.
Figura 1: Esquema geral de um processo de desenvolvimento
Na figura acima, temos uma representação rápida sobre os caminhos no
processo de desenvolvimento de uma solução de TI. Para tanto, temos as
7 de 69
Aspectos legais no desenvolvimento de soluções de TI
alternativas normais da contratação para apenas o desenvolvimento de
software, ou a opção de desenvolver o software mais a contratação de
infraestrutura para prover o serviço para o cliente, ou também conhecido como
hospedagem ou hosting. No desenvolvimento, pode ser gerado um programa
para instalação na estação de trabalho, também conhecido como aplicação
desktop, ou acessível pela web, também conhecido como sistema web ou SaaS
(Software as a Service - Software como um Serviço). Dentro deste fluxo,
opcionalmente, pode haver registro e/ou licenciamento deste sistema.
8 de 69
Aspectos legais no desenvolvimento de soluções de TI
2. Definições
Antes de seguir, é fundamental determinar alguns termos comuns para todo o
processo, assim dedicaremos algum tempo para entender estas definições e
sua importância dentro do processo.
2.1. Computação em nuvem (Cloud Computing)
Da Wikipédia1:
“O conceito de computação em nuvem
(em inglês, cloud computing) refere-se
à utilização da memória e das
capacidades de armazenamento e
cálculo de computadores e servidores
compartilhados e interligados por meio
da Internet, seguindo o princípio da
computação
em
grade.
O
armazenamento de dados é feito em
serviços que poderão ser acessados de
qualquer lugar do mundo, a qualquer
hora, não havendo necessidade de
instalação de programas x ou de armazenar dados. O acesso a
programas, serviços e arquivos é remoto, através da Internet - daí a
alusão à nuvem. O uso desse modelo (ambiente) é mais viável do que o
uso de unidades físicas. Num sistema operacional disponível na Internet,
a partir de qualquer computador e em qualquer lugar, pode-se ter acesso
a informações, arquivos e programas num sistema único, independente
de plataforma. O requisito mínimo é um computador compatível com os
recursos disponíveis na Internet. O PC torna-se apenas um chip ligado à
Internet — a "grande nuvem" de computadores — sendo necessários
somente os dispositivos de entrada (teclado, mouse) e saída (monitor).”
2.2. Engenharia reversa
Do sitio Hackers HI2:
Como o próprio nome indica, a Engenharia Reversa é uma engenharia
"ao contrário", portanto, é uma atividade que trabalha com um produto
existente (um software, uma peça mecânica, uma placa de computador,
etc.) e tenta entender como este produto funciona e o que ele faz
exatamente (todas as suas propriedades em quaisquer circunstâncias).
1
2
http://pt.wikipedia.org/wiki/Cloud_computing (2012)
http://hackershi.webnode.com.br/news/engenharia-reversa/ (2012)
9 de 69
Aspectos legais no desenvolvimento de soluções de TI
Fazemos engenharia reversa quando queremos trocar ou modificar uma
peça (ou um software) por outro, com as mesmas características, mas
não temos todas as informações sobre essa peça.
Para o desenvolvimento de software, este processo é especialmente útil
quando temos um sistema em que não temos os fontes, ou não temos mais
suporte do fornecedor, ou para fazer evoluções corretivas e/ou evolutivas
sobre o mesmo.
Pode ainda ser utilizado para se estudar o funcionamento de determinado
tratamento ou regra de negócio que o sistema se prontifique a fazer.
Dependendo da licença, este tipo de estudo é considerado ilegal.
2.3. Framework
Da Wikipedia1:
Um framework, em desenvolvimento de software, é uma abstração que
une códigos comuns entre vários projetos de software provendo uma
funcionalidade genérica. Um framework pode atingir uma funcionalidade
específica, por configuração, durante a programação de uma aplicação.
Ao contrário das bibliotecas, é o framework quem dita o fluxo de controle
da aplicação, chamado de Inversão de Controle.
Em outras palavras, é através do framework que é ditado a forma da equipe
utilizar determinados métodos no desenvolvimento do sistema, métodos como
acessar os dados no banco de dados, ou de como apresentar os dados na tela,
etc.
2.4. Infraestrutura
Podemos abordar de duas formas
desenvolvimento e a de hospedagem.
a
parte
de
infraestrutura:
a
de
Porém, antes de seguir, é importante deixar claro que muitos dos pontos
citados nos itens abaixo ocorrem de acordo com a metodologia e processo
adotado por cada empresa, isto é, podem existir ações descritas abaixo que
são realidade para certas empresas, mas não para outras.
Outro ponto de atenção é que para estas ações, como o gerenciamento de um
projeto, pode ser feito usando desde papel e caneta até um sistema totalmente
integrado com todo o processo produtivo da empresa, dependendo de como foi
implementado na empresa. Agora, no momento em que se emprega o uso de
um sistema, ou ainda, um software é importante que este esteja respeitando
1
http://pt.wikipedia.org/wiki/Framework (2012)
10 de 69
Aspectos legais no desenvolvimento de soluções de TI
integralmente sua licença, isto é, se é um software livre, o uso é garantido sem
pagamento de royalties, porém se é um software de licença fechada, estamos
falando necessariamente em aquisição de licenças, respeitando a referida
licença. Com estes detalhes em mente, vamos analisar os tipos de
infraestrutura em detalhes.
2.4.1. Infraestrutura de desenvolvimento
Para um desenvolvimento nos padrões atuais, em equipe, considera-se o uso
de ferramentas mínimas como:
•
Gestão de projeto - geralmente com foco em cronograma e custos,
dentro dos conceitos do PMBOK;
•
Gestão de configuração - com foco no desenvolvimento, isto é, serviço
de bilhetes (tickets), documentação, planejamento, entre outras funções.
Estas funcionalidades podem estar dentro de um único software,
distribuído entre vários, ou ainda, sob integração abaixo de uma
ferramenta integradora;
•
Gerenciamento de versão - controla todas as alterações do código,
permitindo rastreabilidade, isto é, mostrando quem, quando, fez o que.
Em uma equipe de desenvolvedores, é fundamental para garantir o
controle e evolução do software. Este é um componente dentro da
gestão de configuração;
•
Servidores de desenvolvimento, testes e homologação - para
soluções para web, de acordo que o software é desenvolvido, é
necessário um ambiente para testes, isto é, um servidor para instalar e
testar se o software está atendendo as especificações. Só que neste
processo, precisamos servidores de aplicação e banco de dados, que
podem ou não ficar na mesma máquina, além do sistema operacional
do(s) servidor(es). Para homologação, ocorre o mesmo processo,
tratando-se de um passo adicional de testes, geralmente com o cliente,
para homologar o desenvolvimento;
•
Ativos de rede - necessários para
computadores e servidores da empresa.
interligação
de
todos
os
2.4.2. Infraestrutura de hospedagem
Pode acontecer de a empresa prover apenas hospedagem, isto é, o software é
desenvolvido fora e depois instalado em servidores providos por esta. Para
tanto, se requer:
11 de 69
Aspectos legais no desenvolvimento de soluções de TI
•
Ativos de rede - necessários para
computadores e servidores da empresa;
interligação
de
todos
os
•
DMZ - sigla para “zona desmilitarizada” (do inglês, demilitarized zone),
área da rede que tem contato com a rede externa, isto é, a internet.
Geralmente os servidores web, correio eletrônico, entre outros, ficam
nesta região intermediária;
•
Servidores de produção - idêntico ao ambiente de homologação,
porém, com acesso do usuário final.
Este é um ambiente de alta disponibilidade, com requisitos mais severos de
segurança, estabilidade, redundância e recuperação, com monitoramento ativo
de todo o ambiente, todos são softwares com suas respectivas licenças,
precisando uma análise de suas cláusulas.
É importante ainda ressaltar que ao final de um ciclo de desenvolvimento
existe o processo de evolução de software, que pode ser considerado uma
extensão ou um novo contrato, dependendo do volume de evoluções e/ou
correções necessárias. Assim, estes ambientes podem ir além do
desenvolvimento do software puramente, ou ainda pode ser a internalização
de um produto desenvolvido por terceiros, que recai na mesma situação.
2.5. Licença
Do dicionário Michaelis1:
li.cen.ça
sf (lat licentia) 1 Autorização dada a alguém para fazer ou deixar de fazer
alguma coisa; permissão.
O conceito de licença se desdobra em dois pontos:
1
2
•
Direito autoral: que trata sobre os direitos do autor sobre sua obra intelectual
que pode ser literária, artística ou científica. Este, pelas questões judiciais
clássicas ainda se desdobra em direitos morais, que são os direitos de natureza
pessoal, e os direitos patrimoniais, relacionado a propriedade;
•
Direito de cópia (ou copyright)2: Direitos autorais não são
necessariamente o mesmo que copyright em inglês. O sistema anglosaxão do copyright difere do de direito de autor. Os nomes respectivos já
nos dão conta da diferença: de um lado, tem-se um direito à cópia,
copyright ou direito de reprodução, do outro, um direito de autor; neste,
o foco está na pessoa do direito, o autor; naquele, no objeto do direito (a
obra) e na prerrogativa patrimonial de se poder copiar.
http://michaelis.uol.com.br/moderno/portugues/index.php?lingua=portuguesportugues&palavra=licen%E7a (2012)
http://pt.wikipedia.org/wiki/Copyright (2012)
12 de 69
Aspectos legais no desenvolvimento de soluções de TI
Deve perceber as diferenças entre o direito autoral de origem romanogermânica, com base no sistema continental europeu do chamado Sistema
romano-germânico, e o sistema anglo-americano do copyright baseado no
Common Law, havendo por característica diferencial o fato de que o Direito
Autoral tem por escopo fundamental a proteção do criador e ao contrário o
copyright protege a obra em si, ou seja o produto, dando ênfase à vertente
econômica, à exploração patrimonial das obras através do direito de
reprodução. Na efetuação do direito de reprodução, o titular dos direitos
autorais poderá colocar à disposição do público a obra, na forma, local e pelo
tempo que desejar, a título oneroso ou gratuito.
No Brasil, temos este detalhamento na Lei dos Direitos Autorais, listando
abaixo os principais pontos.
Lei de Direitos Autorais (Lei nº 9.610/98)
Art. 7º São obras intelectuais protegidas as criações do espírito,
expressas por qualquer meio ou fixadas em qualquer suporte, tangível ou
intangível, conhecido ou que se invente no futuro, tais como:
(...)
V - as composições musicais, tenham ou não letra;
VI - as obras audiovisuais,
cinematográficas;
sonorizadas
ou
não,
inclusive
as
(...)
VIII - as obras de desenho, pintura, gravura, escultura, litografia e arte
cinética;
(...)
XII - os programas de computador;
§ 1º Os programas de computador são objeto de legislação específica,
observadas as disposições desta Lei que lhes sejam aplicáveis.
Além dos programas de computador, foram destacados intencionalmente as
questões relacionadas a produções musicais, desenho e audiovisuais. Isto
acontece pois no desenvolvimento de software não se trata somente do código
do programa. Para a construção de um programa precisamos ainda dos ícones,
botões e outros elementos gráficos, alertas sonoros e até animações e textos
na parte de documentação e/ou suporte ao software, que se enquadram na lei
e viram pontos de cuidado no desenvolvimento de uma solução de TI.
13 de 69
Aspectos legais no desenvolvimento de soluções de TI
2.5.1. Licença de software
Da Wikipedia1:
“Uma licença de software é uma definição de ações autorizadas (ou
proibidas) no âmbito do direito de autor de um programador de software
de computador concedidas (ou impostas) ao usuário deste software.
Entende-se por usuário qualquer entidade legal, empresas ou um
"usuário final (doméstico)", origem da expressão end user license
agreement (EULA).
Quando uma licença acrescenta restrições para além das existentes no
direito de autor, o usuário tem normalmente de aceitar que lhe sejam
impostas estas restrições para poder sequer utilizar o software. Aqui
reside a principal diferença entre uma licença de software livre e uma
licença de software não-livre: as licenças de software livre acrescentam
direitos face aos já concedidos pelo direito de autor, deixando apenas
para o ato de redistribuição as únicas regras que impõem.”
Então, a partir desta definição, podemos entender que a licença de software
é, na verdade, um contrato formal e legal entre o autor (programador, para
pessoa física, ou fábrica de software, para pessoa jurídica) e o usuário desta
solução, definindo o que se pode ou não fazer com o software. Entenda-se por
fazer, além do uso do programa, atos como o de redistribuir, vender ou doar,
estudar, modificar ou outra ação relacionada.
Figura 2: O que é licença
1
http://pt.wikipedia.org/wiki/Licen%C3%A7a_de_software (2012)
14 de 69
Aspectos legais no desenvolvimento de soluções de TI
2.5.2. Licença Pública de Marca
Da Instrução Normativa 01/2011, do Governo Brasileiro 1:
(…)
“V - Licença Pública de Marca – LPM: tipo de licença de uso de marca que
preserva a identidade original entre o nome, a marca, o código-fonte, a
documentação e outros artefatos relacionados ao Software Público
Brasileiro e na qual o titular do registro consente genericamente, sem
necessidade de qualquer tipo de autorização prévia e/ou específica, que
outros utilizem gratuitamente a marca para fins de cópia, distribuição,
compartilhamento e transmissão em qualquer dispositivo físico ou
virtual, inclusive com propósitos comerciais, desde que respeitada as
regras e requisitos previstos no Capítulo IV desta Instrução Normativa;”
2.6. Marca
Da Wikipedia2:
“Marca não é um conceito fácil de definir. Na sua definição e na sua
análise devem-se levar em consideração as disciplinas que a utilizam e
regulam mais diretamente, que são o direito comercial e a gestão de
marketing. Para o direito comercial a marca é um sinal.
A OMPI – Organização Mundial de Propriedade Industrial – define a marca
como um “sinal que serve para distinguir os produtos ou serviços
de uma empresa dos outros de outras empresas”. A definição da
American Marketing Association, ainda adotada em edições clássicas de
marketing, acrescenta a definição jurídica: “ A marca é um nome, um
termo, um sinal, ou um desenho, ou uma combinação destes
elementos, com vista a identificar os produtos e serviços de um
vendedor, ou de um grupo de vendedores, e a diferenciá-los dos
concorrentes”. Segundo Kotler, “talvez a habilidade mais
característica dos profissionais de marketing seja a capacidade
de criar, manter, proteger e melhorar uma marca. Para os
profissionais de marketing, o estabelecimento de uma marca é a
arte e a essência do marketing.”
1
2
http://www.governoeletronico.gov.br/acoes-e-projetos/software-livre/licenca-publica-demarca (2012)
http://pt.wikipedia.org/wiki/Marca (2012)
15 de 69
Aspectos legais no desenvolvimento de soluções de TI
2.7. Programa de computador (ou software)
Da Wikipedia1:
“Um programa de computador é a formalização de um algoritmo em
qualquer linguagem capaz de ser transformada em instruções que serão
executadas por um computador gerando os resultados esperados .
O termo "software" pode ser utilizado quando se quer designar um
conjunto de programas ou, mais frequentemente, quando é feita uma
referência à parte não física do sistema computacional, em contraposição
ao termo "hardware", que designa o conjunto de componentes
eletrônicos que constituem um computador.
Os programas de computador utilizados diretamente por pessoas
comuns, como os editores de texto, são chamados de software
aplicativo, ou de aplicação. Os programas voltados para dar suporte
funcional aos computadores, como os sistemas operacionais, são
chamados de software de sistema. Esses softwares, assim como aqueles
embutidos em outros sistemas (firmware2), podem ser genericamente
chamados de "programas".”
Da Lei do Software (Lei 9.609/98)3:
“Art. 1º Programa de computador é a expressão de um conjunto
organizado de instruções em linguagem natural ou codificada, contida
em suporte físico de qualquer natureza, de emprego necessário em
máquinas automáticas de tratamento da informação, dispositivos,
instrumentos ou equipamentos periféricos, baseados em técnica digital
ou análoga, para fazê-los funcionar de modo e para fins determinados.”
2.8. Registro de programas de computadores
O registro de programas de computadores constitui no depósito de uma cópia
do programa em um órgão credenciado para garantir a autoria. No Brasil, a
competência é do Instituto Nacional de Propriedade Industrial 4 – INPI, que foi
atribuída através do Decreto 2.556/98 e, também, é regido pela Lei nº
9.609/98, conhecida como Lei do Software e a Lei nº 9.610/98, a Lei de Direitos
Autorais.
1
2
3
4
http://pt.wikipedia.org/wiki/Programa_de_computador (2012)
firmware é o conjunto de instruções operacionais programadas diretamente no hardware
de um equipamento eletrônico. É armazenado permanentemente num circuito integrado
(chip) de memória de hardware, como uma ROM, PROM, EPROM ou ainda EEPROM e
memória flash, no momento da fabricação do componente.
http://www.planalto.gov.br/ccivil_03/leis/l9609.htm (2012)
http://www.inpi.gov.br/ (2012)
16 de 69
Aspectos legais no desenvolvimento de soluções de TI
Para questões internacionais, os regimentos jurídicos para a proteção de
software para o direito de autor são estabelecidas pela Convenção de Berna e
pelas disposições do Acordo sobre Aspectos da Propriedade Intelectual
Relativos ao Comércio - TRIPS.
2.9. Tecnologia
Ou ainda chamado de cenário tecnológico, são as definições das questões
arquiteturais, tais como linguagem a ser utilizada, qual banco de dados usar,
arranjos de rede como balanceamento e IPs virtuais, os servidores e
dispositivos de armazenamento e cópia de segurança.
A partir dos pré-requisitos levantados, estima-se os softwares envolvidos na
parte de desenvolvimento, como IDE (Integrated Development Envirounment)
para a linguagem escolhida, gerenciamento de configuração, controle de
versionamento e controle de qualidade; e na parte de infraestrutura, como
sistema operacional do(s) servidor(es), se este(s) servidor(es) será(ão)
virtualizado(s) deverá constar ainda o software de virtualização, e ainda os
softwares de servidor de aplicação, onde rodará o sistema a se desenvolver em
caso de web, e banco de dados, além dos preparativos de rede, seja para
ambientes de teste e homologação, no caso de desenvolvimento apenas, e
produção, para o caso de também hospedagem.
Para todos estes componentes existem licenças, que podem precisar ser
adquiridas para o desenvolvimento do projeto. Alguns destes softwares podem
já ter sido adquiridas para outros projetos, porém podem ter limitações
relacionados a quantidades de acessos e/ou produtos instalados.
De qualquer forma, estes pontos são relevantes no aspecto financeiro, o que
foge do escopo deste artigo, que foca apenas nos aspectos legais, buscando
levantar os pontos de preocupação sob o ponto de vista jurídico do processo.
2.10. Virtualização
Da Wikipédia1:
A Virtualização de Servidor é a técnica de execução de um ou mais
servidores virtuais sobre um servidor físico. Permite maior densidade de
utilização de recursos (hardware, espaço e etc), enquanto permite que
isolamento e segurança sejam mantidos. Com a Virtualização de
Servidor, conquista-se os seguintes benefícios:
•
1
Consolidação de Servidores: Muitos servidores implantados
pelas organizações são subutilizados. Implantando múltiplos
http://pt.wikipedia.org/wiki/Virtualiza%C3%A7%C3%A3o_de_servidor (2012)
17 de 69
Aspectos legais no desenvolvimento de soluções de TI
servidores em um numero menor de servidores físicos, é possível
aumentar a utilização média de recursos dos servidores, enquanto
diminui o numero de máquinas. Na maioria das organizações,
consolidar os servidores com Virtualização de Servidores diminui os
gastos com eletricidade, consumo de espaço e etc.
18 de 69
•
Isolamento de Aplicação ou Serviço: Com a criação de
máquinas virtuais isoladas, a execução dos serviços e aplicações é
feita em Sistemas Operacionais diferentes. Isso previne que uma
aplicação afete outra quando você faz uma atualização ou
mudança. Isso se torna melhor do que executar diversas aplicações
em um único sistema operacional.
•
Implantação de Servidores Simplificada: Com a criação de
imagens padrão de servidores virtuais, você pode implantar
máquinas virtuais de forma muito mais simples. Como você está
implementando um servidor virtual, você também não precisa
fazer aquisição de um novo Hardware, e localizar espaço e energia
elétrica em um Data Center. (Observando sempre a utilização de
recursos compartilhados dentro de um Host, você pode ter que
adquirir um novo hardware para executar suas máquinas virtuais)
•
Maior disponibilidade de Aplicações e Serviços: Como a
aplicação ou serviço não está mais conectado diretamente a um
hardware específico, é mais fácil assegurar disponibilidade e
recuperação. Algumas tecnologias permitem, inclusive, migrar uma
máquina virtual de um host a outro host sem interrupção da
máquina virtual.
•
Múltiplos Sistemas Operacionais podem ser executados
uma única plataforma: Com a virtualização, é possível utilizar
diferentes Sistemas Operacionais em um único servidor físico,
como Linux, Mac OSX, e até mesmo Windows Server 2003 e
Windows Server 2008.
Aspectos legais no desenvolvimento de soluções de TI
3. Breve classificação de software
Classificar software não é uma tarefa trivial, pois ao tentar criar uma
classificação empregamos características comuns, ou ainda, as coisas que
podemos fazer ou não com o software, ações estas devidamente registradas
em suas respectivas licenças. Desta forma, classificar software e classificar
licença de software é praticamente a mesma coisa, uma vez que se
começamos a citar características como direito a usar ou direito a ter acesso
aos códigos-fonte, existirão cláusulas no contrato de uso ou licença.
Para iniciar a entender as diferenças dos softwares sob o critério de
licenciamento, isto é, fazendo uma análise com base na experiência do usuário
final e comparando as principais diferenças a partir de uma análise simples
considerando sua restritividade, ou ainda, uma classificação a partir do que se
pode fazer ou não, coisas como usar em um ou mais computadores, distribuir,
estudar (com ou sem engenharia reversa), modificar, vender, entre outras
ações. Na figura abaixo apresenta os principais tipos de licenças, e em
seguida, discutido com mais detalhes.
Figura 3: Classificação básica de licenças de software
19 de 69
Aspectos legais no desenvolvimento de soluções de TI
3.1. Licenças fechadas
Estas são do tipo mais conhecidas na atualidade, uma vez que a ideia de
vender softwares surgiu na década de 1980, principalmente depois do
acordo entre IBM, com seu Personal Computer - PC, e a Microsoft, com o DOS,
seu sistema operacional, o qual ficou acordado a venda de licenças de uso do
sistema operacional para cada computador vendido. Antes disso, o software
era compartilhado entre os programadores, de uma maneira informal.
Dentre estas modalidades de licenças, elas tem em comum o fato de o usuário
poder utilizar o software como foi distribuído, deixando claro o copyright e
direitos autorais, não sendo permitido outras ações. Vejamos mais detalhes
das principais.
3.1.1. Adware
Adware é qualquer programa que executa automaticamente, mostra ou baixa
publicidade, vírus, trojan, worm, spyware, keylogger, hijaker, rootkit e splitoff
para o computador depois de instalado ou enquanto a aplicação é executada.
Alguns programas shareware são também adware, e neles os usuários têm a
opção de pagar por uma versão registrada, que normalmente elimina os
anúncios.
Figura 4: Gerenciador de
downloads FlashGot
Figura 5: Navegador Web
Opera
3.1.2. Freeware ou Gratuito
Software gratuito ou freeware é qualquer programa de computador cuja
utilização não implica o pagamento de licenças de uso ou royalties. É
importante não confundir o free de freeware com o free de free software, pois
no primeiro uso o significado é de gratuito, e no segundo de livre. Um
programa licenciado como freeware não é necessariamente um software livre,
pode não ter código aberto e pode acompanhar licenças restritivas, limitando o
uso comercial, a redistribuição não autorizada, a modificação não autorizada
ou outros tipos de restrições.
20 de 69
Aspectos legais no desenvolvimento de soluções de TI
Figura 6: Leitor de
PDF Acrobat Reader
Figura 7: Plugin web
Oracle Java
3.1.3. Instalado em um computador ou OEM1
OEM é a sigla para Original Equipment Manufacturer. Com este modo de
aquisição, você tem software ou produtos da Microsoft pré-instalados quando
você compra um computador ou um servidor. Assim, o hardware é fornecido
com uma ou mais licenças individuais. Atenção: esta licença está ligada à
máquina e não pode ser reinstalada em outra máquina. É necessário comprar
outra licença quando o computador ou o servidor é substituído.
Figura 8: Sistema Operacional Windows 7
3.1.4. Por volume2 ou integrador
São destinadas a empresas que requerem o uso de cinco ou mais cópias,
cabendo a fornecedora oferecer contratos de licenciamento chamados
licenciamento por volume. Programas de licença por volume são feitos para
corresponder às necessidades da organização. Através de programas de
licenciamento por volume as empresas, da pequena empresa a multinacionais,
podem obter licenças para o software de forma simples e econômica.
Basicamente, é possível discutir valores mais acessíveis em função do volume.
Existem ainda a opção de comprar ou alugar licenças.
Figura 9: Anti-vírus McAfee
Figura 10: Suíte Microsoft Office
1
2
http://msdn.microsoft.com/pt-br/ee872872 (2012)
http://msdn.microsoft.com/pt-br/ee872872 (2012)
21 de 69
Aspectos legais no desenvolvimento de soluções de TI
3.1.5. Software como Serviço (SaaS)
Software como serviço, do inglês Software as a Service, é uma forma de
distribuição e comercialização de software. No modelo SaaS o fornecedor do
software se responsabiliza por toda a estrutura necessária para a
disponibilização do sistema (servidores, conectividade, cuidados com
segurança da informação) e o cliente utiliza o software via internet, pagando
um valor recorrente pelo uso.
Não é necessariamente a tecnologia utilizada que determina o modelo. O
software utilizado pode ser 100% web (utilizado via navegador) ou pode ter
alguma instalação local (como antivírus ou sistemas de backup). A
característica principal é a não aquisição das licenças (mas sim pagar pelo uso
como um "serviço") e a responsabilidade do fornecedor pela disponibilização
do sistema em produção.
Figura 11: Microsoft Office 365
Figura 12: Webmail Gmail
3.1.6. Shareware (ou Trial)
Shareware é um programa de computador disponibilizado gratuitamente,
porém com algum tipo de limitação. Sharewares geralmente possuem
funcionalidades limitadas e/ou tempo de uso gratuito do software limitado,
após o fim do qual o usuário é requisitado a pagar para acessar a
funcionalidade completa ou poder continuar utilizando o programa. Um
shareware está protegido por direitos autorais.
O freeware diferencia-se do shareware, no qual o usuário deve pagar para
acessar a funcionalidade completa ou tem um tempo limitado de uso gratuito.
Figura 13: Compactador
WinRAR
22 de 69
Figura 14: Segurança Web
Symantec
Aspectos legais no desenvolvimento de soluções de TI
3.1.7. Licenciamento Único, de Caixa ou FPP (Full Packaged
Product)1
Essas licenças trazem em uma única caixa a licença, os direitos de uso /
instalação e documentação (daí seu nome). A instalação deste software é
permitida em um único computador. Licenças na caixa são adequadas para
microempresas, com um a três computadores e estão disponíveis em vários
distribuidores especializados, lojas online ou varejo.
Figura 15: Desenho
vetorial CorelDRAW
Figura 16: Edição de
imagens PhotoShop
3.2. Estudos de casos para licenças fechadas
Para a maioria dos usuários estes são programas corriqueiros, acessíveis em
qualquer vendedor ambulante com preços módicos, no entanto, ao comprarem
por estes meios caracterizam uma série de irregularidades, sendo a pirataria
a mais comum. Vejamos com mais cuidado alguns outros casos para entender
melhor estes problemas.
•
Distribuição de software
Em situações em que uma empresa, seja pública ou privada, disponibiliza
documentos em formato PDF, geralmente coloca um link para baixar o
Acrobat Reader. Se o link enviar o usuário para o portal web da empresa,
como a Adobe no caso do Acrobat Reader, para baixar o programa está
tudo certo, no entanto, algumas empresas disponibilizam o programa a
partir do seu próprio portal, o que, pela licença, não é permitido.
Em situação similar, também ocorre um erro muito comum no
desenvolvimento de software. Independente de sua função, geralmente é
necessário um banco de dados para armazenar os dados, então o
desenvolvedor distribui dentro do instalador do seu programa um
instalador do banco de dados, que caracteriza o mesmo exemplo
anterior, gerando um litígio pois a licença não permite tal ação;
•
1
Uso em mais de um computador
http://msdn.microsoft.com/pt-br/ee872872 (2012)
23 de 69
Aspectos legais no desenvolvimento de soluções de TI
Em softwares de licença única, como o nome diz, é para um único
computador. A instalação em um segundo equipamento com o mesmo
número de série constitui em quebra do contrato.
De forma análoga, existem programas que são gratuitos para o primeiro
equipamento doméstico, mas ao instalar em um segundo, este precisa
de uma licença adquirida (geralmente comprada). É um erro comum do
usuário apenas ler o “gratuito” e distribuir instalações. O problema se
agrava quando se trata de micro e pequenos negócios;
•
Estudos e divulgação de informações
Este talvez seja o mais problemático de todos, pois refere-se ao trabalho
do usuário, que pode encontrar problemas no uso (bugs) ou estudar o
funcionamento do programa de computador, sendo que estas ações são
proibidas pela licença.
O melhor exemplo para este tipo de problema
aconteceu em 2001 com o programador de
computadores Dmitri Sklyarov, cidadão russo
que na época tinha 26 anos, era aluno de
doutorado em computação na prestigiosa
Bauman Moscow State Technical University,
pai de dois filhos, descobriu uma falha na
segurança do software para livros eletrônicos
da empresa Adobe Systems. Depois de várias
tentativas de comunicar a falha para a referida
empresa, resolveu publicar na internet suas
descobertas e alertas, e foi convidado para o
mais famoso evento de segurança, o DefCon,
no EUA. Após apresentar sua palestra, foi
preso pelo FBI por quebrar as cláusulas de Figura 17: Dmitry Sklyarov (2010)
sigilo sobre informações dos e-books da
Adobe. Este tipo de tratamento de problemas
do software efetivamente não ajudam ao usuário final em ter produtos
mais seguros. Não adianta ocultar os problemas, esperando que não
sejam vistos, e sim o contrário, podendo contar com uma infraestrutura
de segurança ampla e o apoio do coletivo. Para mais detalhes da história
de Sklyarov, acesse estas referências1 2;
3.3. Software proprietário vs Software privativo
1
2
http://www.cic.unb.br/docentes/pedro/sd.php (2012)
http://www.numaboa.com.br/informatica/aprendiz/mundo-hacker/799-Dmitry-Sklyarov
(2012)
24 de 69
Aspectos legais no desenvolvimento de soluções de TI
Um erro comum de interpretação foi que os softwares de licenças pagas
fossem denominados de proprietário, dando a ilusão que as demais licenças
não tenham propriedade, que é um conceito errado.
Na verdade, todo e qualquer software tem um ou mais proprietários. No caso
de empresas que desenvolvem software, o direito patrimonial pertence a esta,
e o direito moral, aos desenvolvedores, empregados desta empresa. No caso
de projetos de código aberto ou software livre, o direito patrimonial e moral de
cada contribuição é respeitada e passível de rastreabilidade, ou seja, é possível
determinar cada trecho do código e seu respectivo autor desde a sua criação
(quando existe uma adoção disciplinada de gestão de configuração).
Roberto Brenlla, da Espanha, apresentou uma definição nova e, na minha
opinião mais acertada, que foi do termo software privativo, isto é, aqueles
que a licença priva o usuário de uma série de ações, tais como distribuir,
estudar, modificar ou mesmo usar sob determinadas condições.
Desta forma, todas as referências a softwares com licenças fechadas serão
referenciados como software privativo.
3.4. Licenças compartilhadas
Código compartilhado é um termo genérico que cobre alguns dos mecanismos
legais da Microsoft para o software com distribuição do código-fonte. A
Iniciativa de “Código Compartilhado da Microsoft” 1, lançado em Maio de 2001,
inclui um espectro de tecnologias e licenças. A maioria de suas ofertas de
código-fonte estão disponíveis para descarga após os critérios de elegibilidade
estarem cumpridos.
As licenças associadas ao conjunto de ofertas de código fechado podem
permitir apenas visualização do código para referência ou permitem que ele
seja modificado e redistribuído, tanto para fins comerciais e não comerciais.
Para os analistas da área, esta foi uma estratégia adotada pela Microsoft para
combater os projetos de código aberto (open source), pois uma das principais
argumentações para a adoção destas soluções em relação às pagas era a
questão de auditoria de código, ou seja, que com soluções pagas geralmente
usamos como está, uma “caixa preta”, que não sabemos o que faz ou como
faz, ou ainda se faz apenas o que se propõe.
3.5. Licenças abertas
Diferente das outras duas modalidades, fechada e compartilhada, as licenças
abertas são assim chamadas por disponibilizar acesso aos arquivos fontes sem
restrições, o que permitem uma série de outras ações além de usar o
1
http://www.microsoft.com/resources/sharedsource/default.mspx (2012)
25 de 69
Aspectos legais no desenvolvimento de soluções de TI
programa. Apesar disto, pode-se fazer uma subclassificação em relação a
questões filosóficas e de propriedade. Vejamos com mais cuidado cada grupo.
3.5.1. Software livre
Da Wikipédia1:
Software livre, segundo a definição criada pela Free Software Foundation,
é qualquer programa de computador que pode ser usado, copiado,
estudado e redistribuído sem restrições. O conceito de livre se opõe ao
conceito de software restritivo (software proprietário), mas não ao
software que é vendido almejando lucro (software comercial). A maneira
usual de distribuição de software livre é anexar a este uma licença de
software livre, e tornar o código-fonte do programa disponível.
Um software é considerado como livre quando atende aos quatro tipos de
liberdade para os usuários do software definidas pela Free Software
Foundation:
Liberdade 0: A liberdade para executar o programa, para qualquer
propósito;
Liberdade 1: A liberdade de estudar como o programa funciona, e
adaptá-lo para as suas necessidades;
Liberdade 2: A liberdade de redistribuir, cópias de modo que você possa
ajudar ao seu próximo;
Liberdade 3: A liberdade de modificar o programa e liberar estas
modificações, de modo que toda a comunidade se beneficie.
Acesso ao código-fonte é um pré-requisito para as liberdades de 1,2,3.
A liberdade de executar o programa significa que qualquer tipo de pessoa física
ou jurídica pode utilizar o software em quantas máquinas quiser, em qualquer
tipo de sistema computacional, para qualquer tipo de trabalho ou atividade,
sem nenhuma restrição imposta pelo fornecedor.
A liberdade de redistribuir o programa executável (em formato binário)
necessariamente inclui a obrigatoriedade de disponibilizar seus códigos-fonte.
Caso o software venha a ser modificado e o autor da modificação queira
distribuí-lo, gratuitamente ou não, será também obrigatória a distribuição do
código-fonte das modificações, desde que elas venham a integrar o programa.
Não é necessária a autorização do autor ou do distribuidor do software para
1
http://pt.wikipedia.org/wiki/Software_livre (2012)
26 de 69
Aspectos legais no desenvolvimento de soluções de TI
que ele possa ser redistribuído, já que as licenças de software livre assim o
permitem.
Para que seja possível estudar ou modificar o software (para uso particular ou
para distribuir) é necessário ter acesso ao código-fonte. Por isso a
disponibilidade desses arquivos é pré-requisito para a liberdade do software.
Cada licença determina como será feito o fornecimento do código-fonte para
distribuições típicas, como é o caso de distribuições em mídia portátil somente
com os códigos binários já finalizados (sem o fonte).
Para que essas liberdades sejam reais, elas devem ser irrevogáveis. Caso o
desenvolvedor do software tenha o poder de revogar a licença, o software não
é livre.
As licenças de software livre podem ser divididas em duas subcategorias:
protecionistas totais e parciais.
3.5.1.1. Protecionistas Totais
De acordo com Vanessa Sabino 1, explica que as licenças protecionistas totais
determinam que qualquer trabalho derivado precisa ser distribuído sob os
mesmos termos da licença original. Isso também é chamado de copyleƒt, um
termo criado pela Free Software Foundation2. A ideia do copyleƒt é dar
permissão a todos para executar, copiar, modificar e distribuir versões
modificadas do programa, mas impedir que sejam adicionadas restrições a
essas versões redistribuídas. Tal ideia visa fortalecer o software livre como um
todo, não permitindo que melhorias do software sejam retiradas do alcance da
comunidade. O resultado esperado é que a quantidade de software livre
aumente cada vez mais, beneficiando todos os envolvidos na cadeia produtiva
do software livre. Além disso, a reciprocidade contribui para manter a
compatibilidade entre diversas versões de um determinado sistema, dado que
quando novas funcionalidades são feitas de forma fechada, fica mais difícil
replicá-las nas diferentes versões. Por outro lado, tal abordagem também sofre
críticas de dentro da comunidade, pois o software licenciado nesse modelo
acaba ficando de certa forma isolado dos demais devido a incompatibilidades
nas licenças. Na pratica, software licenciado sob o modelo permissivo, em
geral, pode ser incorporado em software licenciado como recíproco, já que
licenças permissivas permitem a redistribuição sob outros termos, inclusive os
de licenças protecionistas. Porém, o inverso não é verdadeiro e, assim,
software sob licenças protecionistas não pode ser utilizado em vários projetos
de software livre que usam alguma outra licença.
Desta forma, as licenças do tipo protecionistas totais também são
referenciadas como licenças “viróticas”, pois para poder ser distribuída como
1
2
http://ccsl.ime.usp.br/files/relatorio-licencas.pdf (2012)
http://www.gnu.org/copyleft (2012)
27 de 69
Aspectos legais no desenvolvimento de soluções de TI
componente principal ou parte de uma solução maior, as demais partes
também precisam ou trocar a licença para GPL (caso os demais componentes
estejam licenciados sob outra licença), ou não deixar a cargo do usuário buscar
os demais componentes, já que a licença não permite a distribuição conjunta.
São bons exemplos deste tipo de licença a GPL 1 – General Public License
(Licença Pública Geral2), nas suas versões 2.0 e 3.0, e a licença AGPL 3 – Affero
General Public License (Licença Pública Geral Affero4).
A GNU GPL, ou simplesmente GPL, é a designação da licença para software
livre idealizada por Richard Matthew Stallman em 1989, no âmbito do projeto
GNU da Free Software Foundation (FSF). A licença GPL foi originalmente
publicada em Janeiro de 1989. No entanto, passado pouco tempo, ficou claro
que o texto da licença comportava vários problemas, pelo que em Junho de
1991 foi publicada a GPL versão 2, sendo ao mesmo tempo introduzida uma
nova licença LGPL. Em 2005, Stallman anunciou que estava preparando uma
nova versão da licença em conjunto com Eben Moglen. Essa nova versão, foi
chamada de GPLv3 e o primeiro esboço foi publicado em 16 de Janeiro de
2006, sendo a versão final lançada em 29 de Junho de 2007.
A GNU Affero General Public License (Licença Pública Geral Affero GNU), ou
simplesmente GNU Affero GPL, é uma licença de software livre publicada em
2007 pela Free Software Foundation. A GNU AGPL tem o propósito de ser uma
licença minimamente modificada da GNU GPL e atender as necessidades de
fornecer liberdade em softwares como serviços (SaaS, Software as a Service),
ou seja, aqueles os quais você não tem acesso direto ao binário/código-objeto.
1
2
3
4
http://pt.wikipedia.org/wiki/GNU_General_Public_License (2012)
http://www.gnu.org/copyleft/gpl.txt (2012)
http://pt.wikipedia.org/wiki/GNU_AGPL (2012)
http://www.gnu.org/licenses/agpl-3.0.txt (2012)
28 de 69
Aspectos legais no desenvolvimento de soluções de TI
Abaixo, alguns exemplos que utilizam esta licença.
Exemplos de GPL
Figura 18: Media
Player VLC
Exemplos de AGPL
Figura 19: S.
Operacional
Linux
Figura 20: Ambiente de
Desenvolvimento
Launchpad
Figura 21: Conector de
agenda e e-mail
Funambol
3.5.1.2. Protetivas Parciais
Também citado no trabalho de Vanessa Sabino, as licenças protecionistas
parciais, também chamadas de copyleft fraco, determinam que modificações
do trabalho coberto por elas devem ser disponibilizadas sob a mesma licença.
Porém, quando o trabalho é utilizado apenas como um componente de outro
projeto, esse projeto não precisa estar sob a mesma licença. Alguns autores,
como Simon Phipps, utilizam a denominação licença baseada em arquivo para
essa categoria, enquanto as protecionistas totais seriam licenças baseadas em
projeto. Considera-se que essas licenças são as que melhor equilibram dois
importantes fatores do modelo de software livre: atração de interesse para a
comunidade e força e longevidade do código-fonte disponível. Ao mesmo
tempo que essas licenças permitem que os desenvolvedores utilizem o
trabalho para criar software que será licenciado como preferirem, modificações
e melhorias feitas ao próprio trabalho são obrigatoriamente disponibilizadas à
comunidade. Alguns advogados, como Lawrence Rosen 1, defendem que o uso
de bibliotecas que são apenas ligadas a um novo software não caracterizaria
um trabalho derivado, mas sim um trabalho coletivo. Ele faz uma analogia a
páginas na web, em que cada uma é um trabalho com direito autoral
individual, apesar de muitas vezes estariam presentes ligações de uma para a
outra. Segundo ele, esse tipo de relação consiste em uni trabalho coletivo.
Portanto, nesse cenário, mesmo uni software sob uma licença protecionista
total poderia ser usado como biblioteca de outro que estaria sob outra licença.
Porém, no caso brasileiro, a Lei de Direito Autoral é mais específica e impõe
maiores limitações. Dessa forma, o uso de licenças protecionistas parciais fazse necessário em casos nos quais o autor quer garantir que o desenvolvimento
da biblioteca seja feito no modelo de software livre mas ao mesmo tempo quer
permitir seu uso em projetos que utilizam outras licenças.
1
http://www.rosenlaw.com/Rosen_frontmatter.pdf (2012)
29 de 69
Aspectos legais no desenvolvimento de soluções de TI
São exemplos de licenças deste tipo a LGPL 1 – Lesser General Public License
(Licença Pública Geral Menor2) e a MPL3 – Mozilla Public License (Licença
Pública Mozilla4).
A GNU Lesser General Public License, escrita por Richard Stallman e Eben
Moglen em 1991 (e atualizada em 1999), é uma licença de software livre
aprovada pela FSF e escrita como um meio-termo entre a GPL e licenças mais
permissivas, tais como a licença BSD e a licença MIT. A principal diferença
entre a GPL e a LGPL é que esta permite também a associação com programas
que não estejam sob as licenças GPL ou LGPL, incluindo Software privativo.
Outra diferença significativa é que os trabalhos derivados, que não estão sob a
LGPL, devem estar disponíveis em bibliotecas. A LGPL acrescenta restrições ao
código-fonte desenvolvido, mas não exige que seja aplicada a outros softwares
que empreguem seu código, desde que este esteja disponível na forma de uma
biblioteca. Logo, inclusão do código desenvolvido sob a LGPL como parte
integrante de um software só é permitida se o código-fonte for liberado. A LGPL
visa à regulamentação do uso de bibliotecas de código, mas pode ser
empregada na regulamentação de aplicações, como OpenOffice.org e Mozilla.
Outra característica importante é a possibilidade de conversão de apenas uma
parte de um código sob a LGPL em outro, sob a GPL (ver seção 3 da licença).
Já a licença pública Mozilla (Mozilla Public License, em inglês) é uma licença
para software livre de código aberto. A advogada Mitchell Baker criou a versão
1.0 quando trabalhava na empresa Netscape Communications Corporation e a
versão 1.1 quando trabalha na Mozilla Foundation. O seu principal uso é na
suíte de software Mozilla e nos softwares relacionados a ela. Ela foi adaptada
por outras organizações, como no caso da licença Common Development and
Distribution License do sistema operativo OpenSolaris (uma versão de código
aberto do sistema Solaris 10) da Sun Microsystems. A licença é similar ao
copyleft, mas não é tão rígida quanto à distribuição de trabalhos derivados.
Especificamente, o código-fonte copiado ou alterado sob a licença Mozilla deve
continuar sob esta licença. Porém, este código pode ser combinado em um
programa com arquivos proprietários. Além disso, é possível criar uma versão
proprietária de um código sob a licença Mozilla. Por exemplo, o navegador
Netscape 6 e 7 são versões proprietárias das versões correspondentes da suíte
Mozilla. Adicionalmente, os pacotes de software da Mozilla Foundation incluem
logos, ícones, a palavra "Mozilla", e referências a outras marcas. A fundação
utiliza a seguinte política para restringir a redistribuição: a obrigação de
inclusão de citação do autor, de forma similar à obnoxious advertising clause
(cláusula de propaganda detestável, como era chamada pelo projeto GNU) das
1
2
3
4
http://pt.wikipedia.org/wiki/LGPL (2012)
http://www.gnu.org/copyleft/lesser.txt (2012)
http://pt.wikipedia.org/wiki/Licen%C3%A7a_p%C3%BAblica_Mozilla (2012)
http://www.mozilla.org/MPL/1.1/index.txt (2012)
30 de 69
Aspectos legais no desenvolvimento de soluções de TI
primeiras versões da licença BSD; e a impossibilidade de menção quando
determinado projeto é derivado de qualquer versão da suíte Mozilla, do Firefox
ou softwares relacionados. A suíte Mozilla e o Firefox será "relicenciada" sob a
licença GNU General Public License (GPL), pela licença GNU Lesser General
Public License (LGPL) como também pela licença Mozilla. No final o código terá
uma licença tripla, ou seja, serão licenciados sob a licença Mozilla, GPL e LGPL.
Recentemente, a MPL foi revisada, contando com a interação de vários notórios
participantes do código aberto e software livre, como a Free Software
Foundation, que apoiou o seu lançamento 1, atingindo sua versão 2.02, e como
foi informado no portal Br-Linux3:
“descrita como similar em espírito às versões anteriores (que além de
tornarem livre o software a que se referirem, também disponibilizam
formalmente a permissão de uso e redistribuição das tecnologias
patenteadas relacionadas a ele e de propriedade do licenciador) mas
mais curta, melhor e mais compatível com outras licenças livres e de
código aberto”.
Exemplo disso está explicado no FAQ do licenciamento 4, onde aborda tanto o
uso da MPL 2.0 com licenças como a GPL, do universo do software livre, quanto
licenças como Apache e BSD, do universo do código aberto.
Além disto, a Mozilla Foundation disponibilizou o processo de revisão 5,
apontando as modificações, apesar de recomendarem ler a versão final do que
buscar entender estas modificações.
Abaixo, alguns exemplos de software com licenças protecionistas parciais.
Exemplos de LGPL
Figura 22:
Framework
Demoiselle
1
2
3
4
5
Exemplos de MPL
Figura 23: Corretor
Gramatical CoGroo
Figura 24: Navegador
Web Mozilla Firefox
Figura 25: Sistema de
bilhetagem Bugzilla
http://www.fsf.org/blogs/licensing/mpl-2.0-release (2012)
http://www.mozilla.org/MPL/2.0/index.txt (2012)
http://br-linux.org/2012/mpl-2-0-nova-versao-da-mozilla-public-license/ (2012)
http://www.mozilla.org/MPL/2.0/FAQ.html (2012)
http://www.mozilla.org/MPL/2.0/differences.html (2012)
31 de 69
Aspectos legais no desenvolvimento de soluções de TI
3.5.2. Software público
Da Instrução Normativa 01/2011, do Governo Brasileiro:
(...)
Art. 2° O Software Público Brasileiro é um tipo específico de software que
adota um modelo de licença livre para o código-fonte, a proteção da
identidade original entre o seu nome, marca, código-fonte,
documentação e outros artefatos relacionados por meio do modelo de
Licença Pública de Marca – LPM e é disponibilizado na internet em
ambiente virtual público, sendo tratado como um benefício para a
sociedade, o mercado e o cidadão, conforme as regras e requisitos
previstos no Capítulo II desta Instrução Normativa.
A principal diferença entre o software publico e o software livre, do tipo
recíproco total, é a adição de um cuidado adicional em relação a marca através
da LPM, da mesma forma que a GPL busca garantir as mesmas liberdades para
o o código.
Figura 26: Gerenciador de
inventário Cacic
Figura 27: Sistema de
gestão Prefeitura Livre
3.5.3. Código aberto
Da Wikipedia1:
O termo código aberto, ou open source em inglês, foi criado pela OSI
(Open Source Initiative) e refere-se a software também conhecido por
software livre. Genericamente trata-se de software que respeita as
quatro
liberdades
definidas
pela
Free
Software
Foundation,
compartilhadas também pelo projeto Debian, nomeadamente em
"Debian Free Software Guidelines (DFSG)". Qualquer licença de software
livre é também uma licença de código aberto, a diferença entre as duas
nomenclaturas reside essencialmente na sua apresentação. Enquanto a
FSF usa o termo "Software Livre" envolta de um discurso baseado em
questões éticas, direitos e liberdade, a OSI usa o termo "Código Aberto"
sob um ponto de vista puramente técnico, evitando (propositadamente)
1
http://pt.wikipedia.org/wiki/Open_Source (2012)
32 de 69
Aspectos legais no desenvolvimento de soluções de TI
questões éticas. Esta nomenclatura e discurso foram cunhados por Eric
Raymond e outros fundadores da OSI com o objetivo de apresentar o
software livre a empresas de uma forma mais comercial evitando o
discurso ético.
Sabino1 também comenta que as licenças de código aberto também são
conhecidas como “licenças permissivas”, ou também chamadas de licenças
acadêmicas por alguns autores, como Rosen2 e Laurent3, em referência as
origens das licenças BSD (University of California, Berkeley) e MIT
(Massachusetts Institute of Technology), impõem poucas restrições as pessoas
que obtém o produto. Muitas vezes, tais licenças são usadas em projetos de
pesquisa de universidades, que servem como prova de conceito de alguma
tecnologia que poderá ser explorada comercialmente no futuro. No caso das
licenças permissivas, não é feita nenhuma restrição ao licenciamento de
trabalhos derivados, estes podendo inclusive serem distribuídos sob uma
licença fechada. Licenças permissivas são uma ótima opção para projetos cujo
objetivo e atingir o maior número de pessoas, não importando se na forma de
software livre ou de software fechado. Temos vários exemplos desse modelo
no BSD Unix, que continha o software de TCP /IP que hoje é usado na maior
parte das implementações desse protocolo, incluindo a da Microsoft 3. Outro
exemplo é o BIND, Berkeley Internet Name Daemon, cuja implementação livre
é até hoje usada nos principais servidores de DNS, apesar de haver também
varias implementações fechadas. Segundo Laurent 3, ha bilhões de dólares em
atividade econômica associada apenas com a pilha de software para Internet
originalmente liberada sob a licença BSD. Alguns argumentam que o uso desse
tipo de licença não incentiva o modelo de software livre, pois empresas se
aproveitam da comunidade para desenvolver software que sera fechado.
Porém, quando são usadas licenças permissivas, em geral os autores estão
cientes dessa possibilidade e não veem isso como um problema. Um caso
conhecido em que, de fato, os autores se arrependeram da licença que
adotaram é o do Kerberos, desenvolvido no MIT, que posteriormente foi
adotado pela Microsoft, que desenvolveu extensões fechadas 3. Mas o mais
provável, caso a licença não permitisse isso, seria que a Microsoft adotasse
algum outro sistema de segurança e o Kerberos não se tornaria tão popular.
Por outro lado, em alguns casos, não é necessário que haja restrições na
licença para garantir a continuidade do modelo de desenvolvimento aberto,
como no exemplo do servidor Apache. Duas características explicam o domínio
do servidor Web livre no mercado, segundo Laurent3: a marca forte, cujo uso é
1
2
3
http://ccsl.ime.usp.br/files/relatorio-licencas.pdf (2012)
http://www.rosenlaw.com/Rosen_frontmatter.pdf (2012)
http://oreilly.com/openbook/osfreesoft/book/index.html (2012)
33 de 69
Aspectos legais no desenvolvimento de soluções de TI
protegido pela própria licença do Apache, e a importância da conformidade
com os padrões, que evita a disseminação de extensões fechadas.
Além destes exemplos, podemos analisar também a Apple, que desenvolveu o
Mac OSX, sistema operacional baseado no FreeBSD, para seus computadores
Mac. O Mac OSX é um excelente exemplo de fechamento de código. Ainda
dentro do universo de desenvolvimento de software da Apple está o CUPS Common Unix Printing System, é o principal sistema de impressão para os *NIX
em geral, incluindo o próprio OSX, que continua seu desenvolvimento de forma
aberta e colaborativa.
Exemplos BSD
Exemplos MIT
Figura 28: Vídeos
em formato MTK Matroska
Figura 29:
Linguagem de
programação Lua
Figura 31: Sistema
Operacional FreeBSD
Figura 32:
Programas em um
pendrive
PortableApps
Exemplos Apache
Figura 30: Servidor Web Apache
Figura 33: Ferramenta de
compilação java ANT
3.5.4. Domínio público
Da Wikipedia1:
Domínio público, no Direito da Propriedade Intelectual, é o conjunto de
obras culturais, de tecnologia ou de informação (livros, artigos, obras
musicais, invenções e outros) de livre uso comercial, porque não
submetidas a direitos patrimoniais exclusivos de alguma pessoa física ou
jurídica, mas que podem ser objeto de direitos morais.
1
http://pt.wikipedia.org/wiki/Dom%C3%ADnio_p%C3%BAblico (2012)
34 de 69
Aspectos legais no desenvolvimento de soluções de TI
O domínio público está listado aqui e poderia ser usado para licenciar qualquer
software, apesar de não ser usual, no entanto, ele é importante no momento
em que entendemos que um software não é constituído exclusivamente de
código, precisando conter imagens, sons, vídeos e textos, e estes sim precisam
estar devidamente licenciados, mesmo que como domínio público, para não
trazer problemas futuros.
3.6. Novos modelos de negócios com licenças abertas
Tal como existem mudanças consideráveis entre as licenças fechadas e
abertas, estas diferenças influenciaram no modelo mercadológico, fazendo
surgir novos modelos de negócios, com funcionalidades diferenciadas. Dentre
as principais diferenças está a migração do negócio do software como produto
desenvolvido para o serviço, seja como suporte ao usuário, seja no
desenvolvimento corretivo ou evolutivo deste produto. Vejamos alguns
modelos conhecidos.
3.6.1. Subscrição de suporte
Este é um exemplo comum no universo de sistema operacional para
servidores, com empresas como Red Hat ou Novell para suas distribuições
Linux personalizadas.
Apesar de o Linux ser distribuído gratuitamente, não existe um trabalho de
homologação junto as diversos fabricantes de hardware, e é isso que estas
empresas fazem, isto é, fazem testes exaustivos de compatibilidade com os
principais fabricantes, sejam de servidores, unidades de armazenamento
(storages), unidades para cópias de segurança (backup), entre outros. Essa
mesma homologação pode ocorrer com a parte de software, como banco de
dados, servidores de autenticação, firewall, entre outros.
Nestes contratos de subscrição, a empresa garante a compatibilidade com os
produtos homologados, desenvolvem novos produtos, dão suporte de
configuração, além de manter uma estrutura de desenvolvimento para resolver
novos problemas no período determinado no contrato. É gerado um número de
série para garantir a quantidade de instalações e monetizar sobre estes
números.
3.6.2. Contrato de instalação, configuração e suporte
Outras empresas optaram por um processo um pouco diferente, aonde se
preocupa em entender a solução e vender os serviços de instalação,
35 de 69
Aspectos legais no desenvolvimento de soluções de TI
configuração e suporte. Isso acontece para casos como a distribuição Debian,
que não conta com uma empresa comercial por trás do produto, mas sim um
grande ecossistema capaz de dar suporte a este produto, desde pequenas
empresas até grandes do TI mundial, como a HP.
Outro segmento que também acompanha essa estratégia são as de mídias
web, onde são escolhidos CMSs (Content Management System) abertos, como
Drupal, Wordpress ou Joomla, e as empresas personalizam de acordo com as
demandas do cliente.
3.6.3. Estratégia de bilicenciamento
Alguns projetos que nascem de empresas geralmente preferem a ideia de
liberar seu produto sob duas licenças, uma fechada e outra aberta, ou ainda
sob uma licença fechada com exceções FOSS (Free and Open Source
Software). Nesta estratégia se procura popularizar o uso do software através
das comunidades de código aberto, e quando se passa a empregar para
negócios comerciais (ou não-abertas), passa a ser tratado como um software
fechado, com necessidade de licenças, compra e restrições regidas no seu
contrato.
O exemplo mais comum deste tipo de licenciamento é o banco de dados
MySQL, hoje pertencente a Oracle. Quando este banco de dados foi criado, era
fechado até receber propostas de investimentos, somente com a condição de
abrir o código-fonte. Após a abertura do código, o banco se popularizou muito
na internet e valorizou a ponto de chamar a atenção dos grandes jogadores
mundiais de TI, sendo comprado pela Sun Microsystems. Hoje, pertence à
Oracle (pela aquisição da Sun Microsystems por esta) e está licenciada sob
uma licença fechada com cláusula de exceção FOSS 1. Resumidamente, caso
sua aplicação/projeto esteja licenciado sob uma das licenças na página,
reconhecidas pela OSI, o banco de dados MySQL se comportará como GLP,
caso contrário, é uma aplicação paga, como qualquer outra.
3.6.4. Segmentação em comunitário e empresarial
Esta estratégia consiste em desenvolver um núcleo (core) sob uma licença
aberta, em um ambiente de desenvolvimento colaborativo e compartilhado,
com um conjunto de funcionalidades básicos dentro do segmento que pretende
atender, e outra parte fechada, com funcionalidades adicionais estratégicas.
Assim, o desenvolvedor consegue promoção e difusão do seu produto de
maneira rápida, conquistando espaço no segmento de mercado que se propõe,
1
http://mysql.com/about/legal/licensing/foss-exception/ (2012)
36 de 69
Aspectos legais no desenvolvimento de soluções de TI
aderência de força voluntária disposta a ajudar a desenvolver, testar e avaliar
o produto, além de manter o domínio do desenvolvimento e o conhecimento
interno (know-how), dando uma posição privilegiada na integração destas
novas funcionalidades.
São vários os exemplos que seguem esta estratégia de mercado, como o
gerenciador de arquivos Alfresco1 ou o sistema de inteligência de negócios
(businness inteligence – BI) Pentaho2.
3.6.5. Comercialização de produtos abertos - permissivos
Produtos abertos - permissivos são aqueles licenciados sob licenças Apache,
MIT, BSD ou similares. Nestas licenças, como explicado anteriormente, é
necessário respeitar a referência, permitindo a substituição da licença por uma
fechada.
São exemplos deste tipo de uso os produtos da EnterpriseDB 3, uma empresa
que se especializou em evoluir o banco de dados PostgreSQL, que tem uma
licença derivada da BSD também chamada Licença PostgreSQL 4, que permite a
empresa desenvolver ferramentas ao redor do SGBD, além de ajudar no
desenvolvimento do núcleo, tornando a ferramenta ainda mais robusta.
1
2
3
4
http://alfresco.com/ (2012)
http://www.pentaho.com/ (2012)
http://www.enterprisedb.com/ (2012)
http://www.opensource.org/licenses/postgresql (2012)
37 de 69
Aspectos legais no desenvolvimento de soluções de TI
4. Análise dos pontos legais no desenvolvimento
Agora, com os conceitos uniformizados, uma visão geral sobre os tipos de
software e alguns exemplos para correlacionarmos com nosso uso do dia a dia,
temos condições de avaliar melhor o processo de desenvolvimento. Para isso,
vamos considerar o esquema da figura abaixo para entender cada parte do
processo e os cuidados legais necessários no processo.
Figura 34: Visão geral do desenvolvimento - do pedido ao uso
O processo começa com uma demanda do cliente, que estabelece o contato
com a fornecedora de soluções de TIC que, neste caso, é a empresa que
desenvolverá o software. Nesta etapa é definido o escopo do projeto para
poder mensurar e orçar para o cliente. O próximo passo é estimar os custo do
desenvolvimento e, se for o caso, hospedagem, para poder gerar um
orçamento para apresentar ao cliente.
Neste ponto, para poder orçar os custos de desenvolvimento e, se for o caso,
de hospedagem, a empresa tem recursos para parametrizar alguns pontos na
hora de formar a tabela de custos do projeto. Pode acontecer que a empresa já
tenha adquirido licenças de uso, no caso de produtos pagos, que podem ser
reutilizadas ou utilizadas em paralelo nestes novos projetos. Porém, em caso
de ambiente de produção, a forma como for pensada a implantação destas
novas soluções podem precisar novas licenças, assim que é importante uma
38 de 69
Aspectos legais no desenvolvimento de soluções de TI
análise das compras e contratos vigentes junto aos fornecedores, atendando
aos limites destes.
Iniciado o processo de desenvolvimento, isto é, fechado o contrato e
estabelecido o cronograma de trabalho com as etapas bem definidas, inicia-se
a primeira, que é o cenário tecnológico e levantamento de requisitos,
necessário para o desenvolvimento.
No cenário tecnológico será a etapa para avaliar qual será a linguagem de
programação a ser empregada, sistema de gerenciamento de banco de dados
a ser usado e em que ambiente operacional (sistema operacional e ativos de
rede) são necessários para este escopo. A partir do momento que se definem
estes elementos é possível que possam alterar os custos do projeto, pois se
considerar a troca de banco de dados de fechado para aberto irá impactar no
custo final do produto. É possível oferecer alternativas já no orçamento,
demonstrando os custos de desenvolvimento e as opções por utilizar
determinadas tecnologias.
Outro ponto que deve ser analisado, e por vezes escapa da análise das
compras e contratos dos produtos empregados é a questão da virtualização.
Resumidamente, virtualização é a capacidade de criarmos vários servidores
virtuais (VM – virtual machine) sobre um servidor real. Assim, quando
instalamos um software em um servidor virtual, obedece as mesmas regras de
um servidor real, isto é, pode acontecer de termos licenças apenas para
instalar em uma máquina, e distribuirmos o software em várias VMs, o que
pode caracterizar cópias ilegais, dependendo das cláusulas da licença.
Já no levantamento de requisitos é onde o cliente especifica as regras de
negócios e o funcionamento e comportamento esperado pelo sistema a ser
desenvolvido. Nesta etapa, pode ser utilizado desde papel e caneta, editor de
texto ou um sistema de requisitos. Se utilizarmos software precisamos
considerar as licenças de uso.
Ainda nos requisitos, um importante requisito é definir a licença que o
software a ser desenvolvido será disponibilizado. Caso não seja especificado
nenhuma licença, por padrão se adota o direito de propriedade (copyright) do
contratante. Na sequência, é necessário criar os ambientes de
desenvolvimento e homologação, contendo os servidores de aplicação e banco
de dados. É necessário verificar o ambiente de desenvolvimento dos
programadores, o processo de gerenciamento de projeto pela empresa e
gerenciamento de configuração pela fábrica de software (setor operacional de
desenvolvimento). Com todos os detalhes acertados, inicia-se o processo de
codificação. No desenvolvimento do software em si, além de questões de
licenças do ferramental empregado, existem ainda questões trabalhistas, de
uso de obras, de infraestrutura, bibliotecas e outras envolvidas que requerem
uma atenção sob o aspecto jurídico.
39 de 69
Aspectos legais no desenvolvimento de soluções de TI
Uma vez que o software foi desenvolvido, testado e homologado, vem a
entrega deste software, que dá abertura para duas possibilidades:
1) Desenvolvimento – a empresa pode somente desenvolver o software e
a sua implementação pode ocorrer em um ambiente do cliente ou
contratado de terceiros para hospedar esta solução, cabendo a empresa
entregar o produto devidamente licenciado e, opcionalmente, registrado;
ou
2) Desenvolvimento e hospedagem – além de desenvolver, ainda
oferece o serviço de hospedagem, contendo mais um ambiente, o de
produção, onde será disponibilizada a solução para o cliente, precisando
ser devidamente licenciado e, opcionalmente, registrado.
Assim, vamos avaliar cada etapa do processo.
4.1. Cenário tecnológico
De posse do escopo inicial do cliente, os setores de arquitetura e projetos da
empresa vão avaliar as necessidades e estimar os recursos de infraestrutura,
tecnologia, pessoas, entre outros, para atender a demanda.
Elementos que se podem definir nesta etapa que impactam diretamente no
processo é a definição da linguagem de programação, banco de dados e
infraestrutura necessária. Isso acontece porque dependendo da estruturação e
alinhamentos da empresa podem representar custos de aquisição de licenças
em várias partes futuras. Vejamos alguns exemplos.
Cenário
Linguagem
tecnológico
Banco de dados
Ambiente
1
Asp.NET
MS SQL Server
MS Server + IIS + Servidor ASP
2
Java
Oracle
Linux + WebLogic
3
PHP
MySQL
Linux + Apache + Mod PHP
4
Python
PostgreSQL
Linux + Apache + Mod Python
Tabela 1: Diferentes cenários tecnológicos
1. Cenário tecnológico 1
A linguagem de programação Asp.NET, impacta em compra de licenças
das ferramentas de desenvolvimento e no servidor de aplicação Asp.NET.
O banco de dados geralmente apresenta correlação entre linguagem, isto
é, o fornecedor privilegia ou dá mais atenção a determinadas soluções
que, no caso do Asp.NET é para o SQL Server, também da Microsoft. Isso
40 de 69
Aspectos legais no desenvolvimento de soluções de TI
trás a necessidade de adquirir licenças para o banco também. E este
ambiente é projetado para rodar em servidores com Windows Server,
também com necessidade de aquisição de licenças.
2. Cenário tecnológico 2
A linguagem Java dispõe de boas ferramentas de desenvolvimento, tanto
sob licenças abertas quanto fechadas. No caso das ferramentas abertas,
basicamente é baixar, instalar e usar, enquanto que nas fechadas
dependem de aquisição de licenças. A definição do banco de dados
Oracle envolve a aquisição de licenças próprias, apesar de versões
gratuitas para desenvolvedores, não seria possível fazer testes de carga,
por exemplo, fundamental para grandes clientes. E, geralmente ao usar
um banco de dados fechado, influi no processo de desenvolvimento para
se utilizar funções específicas que dão pequenos ganhos, mas que
dificultam uma possível troca futura de tecnologia. Na escolha destes
dois elementos geralmente ocorre uma influencia na escolha do servidor
de aplicação. No exemplo, foi listado um de licença fechada, precisando
ser adquirida a sua licença.
No particular do Java em si, hoje existe uma incerteza sobre seu futuro. A
especificação do Java cabe a JCP – Java Community Process, responsável
por definir os padrões do Java, no entanto, a principal máquina virtual do
mercado é o da Oracle, atualmente gratuito.
3. Cenário tecnológico 3
A linguagem PHP é uma das linguagens de script mais usadas na
internet, com seu interpretador livre, desenvolvido como código aberto.
Roda com os principais bancos de dados do mercado, tanto fechados
quanto abertos, e tem bom suporte nos principais servidores web para
servidor de aplicação. Neste exemplo, o banco de dados empregado foi o
MySQL, atualmente de propriedade da Oracle, sob um bi licenciamento.
Neste licenciamento, basicamente diz que se aplicação está
especificamente sob a licença GPL, o banco se comporta como software
livre, caso contrário, é uma licença comercial. Seu uso deve ser
observado com cautela.
4. Cenário tecnológico 4
A linguagem é o Python, linguagem de script aberta, uma das principais
pelo Google para seu motor de busca, e-mail, entre outros. Com conexão
com os principais bancos de dados aberto, não tem problemas de
conexão com o PostgreSQL e os *NIX (o Linux entre eles) é o ambiente
41 de 69
Aspectos legais no desenvolvimento de soluções de TI
nativo, bem como o servidor de aplicação Apache + Mod Python. Todas
as ferramentas relacionadas com desenvolvimento estão presentes sob
licenças abertas, principalmente, e fechadas.
Em qualquer cenário apresentado são necessários ferramentas de
desenvolvimento, ambientes de desenvolvimento e homologação, gestão de
projeto e configuração.
Como exemplificado nos diferentes cenários, a escolha da tecnologia pode
afetar a questão de custos para o desenvolvimento da solução que,
aparentemente, não afetam as questões jurídicas. No entanto, passam a afetar
caso a empresa use softwares desrespeitando suas licenças, que no caso de
softwares de licença fechada se traduzem na compra do montante
correspondente para atender plenamente as demandas. Veremos o
desdobramento destas questões nos tópicos adiante.
4.2. Início dos trabalhos
Uma vez completado o processo de venda, geralmente com a assinatura do
contrato, inicia-se o trabalho em si. O contrato em si, em geral, consta os
ditames tradicionais garantidos pela legislação, tais como cronograma
aproximado, com abertura de ajustes deste em comum acordo, os valores com
forma de pagamento determinada, e cuidados relacionados a questões de
custos trabalhistas da contratada e isenção da contratante.
Não é normal encontrar detalhamento a respeito de licenciamento do código a
ser desenvolvido, uso de componentes de terceiros, propriedade intelectual,
condições de disponibilização e reuso (caso a licença elegida assim o permita),
entre outros aspectos.
Fechada esta etapa, começa o trabalho organizacional dentro da empresa,
como criação do projeto com a definição das suas etapas. Neste ponto, é
importante utilizar uma ferramenta de gestão de projetos, que pode ser desde
uma planilha até um sistema web de gestão de projetos. A tendência é
trabalhar com o conceito de nuvem, utilizando sistemas multiusuários e
acessíveis a partir de qualquer navegador.
Existem excelentes ferramentas tanto fechadas, que dependem de compra de
licenças de uso para dar acesso interativo das equipes ao sistema, quanto
abertas, que não tem custos. Uma leitura comum encontrada no mercado é
pensar que ao se contratar soluções fechadas os custos estão exclusivamente
sobre a parte de licenças, porém custos adicionais de recursos de terceiros e
personalizações (customizações) do sistema para adequação das necessidades
da empresa elevam consideravelmente o custo. Usando a mesma linha de
pensamento, as soluções abertas também tem seus custos de implantação,
passando pelas mesmas questões de custos nos quesitos de personalização,
42 de 69
Aspectos legais no desenvolvimento de soluções de TI
seja de terceiros/fornecedores, seja das equipes internas que trabalharão neste
processo dentro da empresa. A principal diferença nos dois modelos está, sem
sombra de dúvidas, na questão financeira, mas não só ela. Para modificar um
software, precisa haver as permissões de modificação devidamente registradas
na licença e/ou contrato. No caso de soluções abertas, essas permissões já
estão previamente garantidas.
Ainda dentro do processo de preparação, após a abertura do projeto
propriamente dito, sob uma visão de PMBOK 1, existe a necessidade de se fazer
o ambiente de desenvolvimento, que segue uma linha semelhante à gestão de
projetos, mas com um foco para o desenvolvimento de software em todas suas
etapas. São duas normas ISO/IEC que oferecem um norteamento para isso:
ISO/IEC 122072 e 155043 (SPICE).
Neste ambiente de desenvolvimento, precisamos um software para
documentar os requisitos e documentação. Pode ser usado desde um editor de
texto até sistemas de documentação. Precisamos também um sistema de
versionamento, responsável por fazer a rastreabilidade de todo o
desenvolvimento, entendendo por rastreabilidade a capacidade de identificar
quando, quem e o que cada pessoa da equipe fez. Podemos ter ainda um
sistema de bilhetagem, no qual será registrado todos os erros do sistema
(bugs), novas funcionalidades desejadas (wishlist), controle de qualidade
(quality assurance), testes e homologação. Vejamos um exemplo de ambiente
fechado e aberto, tendo em mente que é possível ter um ambiente misto, com
elementos de um ou outro lado.
Funcionalidade
Exemplo Fechado
®
Gestão de projetos Microsoft Project (desktop), CA
Clarity® (web), ProjectControl®
(web), etc.
Exemplo Aberto
OpenProj (desktop), dotProject
(web), LibrePlan (web), etc.
Documentação
Microsoft Office® (desktop),
Caliber (web), etc.
OpenOffice.org (desktop), Trac
(wiki/web), MediaWiki (web), etc.
Gerencia de
versionamento
MS SourceSafe®, Borland
StarTeam®, etc.
CVS, SVN, Git, etc.
Sistema de
bilhetagem
IBM ClearQuest®, MS Dynamics
CRM®, etc.
Redmine, MantisBT, Trac, etc.
Tabela 2: Produtos por funcionalidade
1
2
3
http://pt.wikipedia.org/wiki/Project_Management_Body_of_Knowledge (2012)
http://pt.wikipedia.org/wiki/ISO/IEC_12207 (2012)
http://pt.wikipedia.org/wiki/ISO/IEC_15504 (2012)
43 de 69
Aspectos legais no desenvolvimento de soluções de TI
A Wikipedia oferece uma boa listagem de comparação de gestão de projetos 1,
controle de versão2 e sistema de bilhetagem3.
Estes sistemas podem ter maior ou menor compatibilidade entre si em termo
de integração e licenças.
Além destes recursos, é necessário definir a ferramenta de desenvolvimento
(IDE - Integrated development environment), onde o desenvolvedor irá
desenvolver o código propriamente dito, os ambientes de desenvolvimento,
geralmente criado na própria estação de trabalho do desenvolvedor com uma
versão reduzida do ambiente de produção, o de teste, onde serão
disponibilizados e integrados todo o código desenvolvido pelo time de
desenvolvimento, e o de homologação, onde os analistas de negócio e até
mesmo o cliente irá avaliar o desenvolvimento do sistema.
São nestes ambientes, de desenvolvimento, de teste e homologação, que será
necessário o servidor de aplicação e banco de dados, especificados pela
arquitetura. Considerando os cenários tecnológicos iniciais, podemos gerar
uma tabela simplificada comparativa.
Func.
Cenário Tec. 1
Cenário Tec. 2
SO estação
Windows®
Windows®
IDE
MS Visual Studio®
Borland Jbuilder®
®
Linux Red Hat
®
Cenário Tec. 3
Cenário Tec. 4
Windows®/Linux
Windows®/Linux
Eclipse
Eclipse/Aptana
Linux
Linux
PostgreSQL
SO servidor
Windows
Banco de
dados
MS SQL Server®
Oracle®
Oracle® MySQL®
Servidor de
aplicação
MS IIS® + ASP
.Net®
Oracle® OAS
Apache + Mod PHP Zope
Tabela 3: Comparativo dos cenários tecnológicos
4.3. Requisitos
A etapa de requisitos consiste basicamente em entender as regras de negócio
do cliente, documentar sob determinada metodologia para que possa ser
encaminhada para a área de desenvolvimento da empresa. Nesta etapa é
importante ter claro o tipo de licenciamento a ser usado, para a devida
inserção no código-fonte, isto é, inserir no cabeçalho de cada arquivo do
sistema desenvolvido informações a respeito da autoria e licença utilizada.
Para ilustrar, segue um exemplo de cabeçalho.
1
2
3
http://en.wikipedia.org/wiki/Comparison_of_project_management_software (2012)
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software (2012)
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems (2012)
44 de 69
Aspectos legais no desenvolvimento de soluções de TI
/**************************************************************
*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
*
http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*
*************************************************************/
// MARKER(update_precomp.py): autogen include statement, do not remove
#include "precompiled_sw.hxx"
(…)
Código 1: Arquivo $SRCROOT/main/sw/source/core/text/blink.cxx
do Apache OpenOffice
4.4. Desenvolvimento
Uma vez que os desenvolvedores recebem os requisitos inicia-se a criação das
tabelas dos bancos de dados, papel destinado ao arquiteto de dados. É criado
um script de criação das tabelas e atribuições necessárias para a parte de
dados. Uma vez criada a base de dados inicial, os programadores começam a
construir a aplicação em si dentro de suas IDEs, sempre integrados com um
controle de versionamento. De acordo que aplicação é construída em suas
respectivas estações de trabalho, periodicamente é feito um teste integrando
todos os códigos no ambiente de testes, verificando como está funcionando a
integração de código dos diversos integrantes da equipe.
Neste ambiente de testes existe um conjunto de configurações, tanto do
servidor de aplicação quanto do banco de dados, que precisa ser replicado nos
ambientes de homologação e produção (quando for o caso).
Geralmente se empregam frameworks para tornar a codificação mais
produtiva, isto é, pedaços de código com funções pré-determinadas, de forma
que o desenvolvedor apenas passe alguns parâmetros para esse framework e
este desenvolva uma série de ações, de maneira simplificada. Além dos
frameworks, é possível que sejam empregadas bibliotecas de terceiros, isto é,
componentes de códigos que fazem determinada função, como por exemplo
gerar relatórios. O desenvolvedor terá que se preocupar apenas em levantar os
dados e um modelo de apresentação e enviar para esta biblioteca, e a
biblioteca se encarrega de criar os arquivos PDFs, com a apresentação
desejada.
45 de 69
Aspectos legais no desenvolvimento de soluções de TI
Durante o desenvolvimento é comum também o uso de imagens,
principalmente em botões ou links, como o de um disquete para indicar a ação
de salvar, ou de uma impressora, para chamar a interface de impressão, ou
ainda uma bandeira para definir o idioma da aplicação. Ainda para a interação
com o usuário pode ser necessário o uso de sons na forma de chamadas, voz
ou música, ou uma forma mais, através de animações ou vídeos.
De acordo que o sistema evolui é necessário desenvolver uma documentação
de apoio, que pode ser um sistema de ajuda, manuais, cursos em EAD ou outra
forma, que possa dar apoio ao usuário em usar e desenvolver seus trabalhos
no sistema criado.
Então, com esta rápida descrição da etapa de desenvolvimento do sistema,
podemos começar a analisar os cuidados para as questões jurídicas envolvidos.
4.4.1. Ambientes
Quando falamos dos servidores de aplicação e banco de dados, estamos
falando de sistema operacional (SO)l do(s) servidor(es) que vai recebê-los,
software de serviço de aplicação, de banco de dados e de softwares adicionais
que sejam necessários. Além disso, existe a parte de infraestrutura de rede,
como firewalls, que também tem questões de licenças a serem consideradas.
No caso do sistema operacional é o software mínimo para operar o
computador. Em caso de SOs Windows ®, Mac OSX ou Solaris, estão sob
licenças fechadas, já o Linux está sob uma licença aberta, sem custos, com
empresas que oferecem contratos de suporte ao ambiente (quando utiliza-se o
Linux personalizado e mantido por eles), como é o caso da Red Hat e
Canonical, e livres como o Debian. Neste ponto, a escolha de determinado
sistema operacional precisará de licenças compradas, contrato de suporte ou
licenças abertas.
Já para o banco de dados também é necessário um cuidado com as licenças,
especialmente para o MySQL. Este banco de dados possui uma licença
comercial com uma exceção FOSS (Free and Open Source Software) que
permite que os componentes da MySQL sejam usadas como licença aberta
somente quando a licença do software em desenvolvimento esteja sob uma
das licenças abertas listada em sua página. Na prática, se está desenvolvendo
um software comercial em licença não-aberta, terá que comprar os
componentes da MySQL Inc.
Ainda vendo os softwares relacionados ao ambiente, a documentação de cada
software envolvido (servidor web, aplicação, banco de dados, etc.) é de
responsabilidade dos respectivos desenvolvedores/ fornecedores, mas o
conjunto de informações de configuração empregados para o desenvolvimento
46 de 69
Aspectos legais no desenvolvimento de soluções de TI
da solução vendida, em si, é parte da documentação do projeto, e precisa estar
presente na documentação final e sob um licenciamento correto, geralmente
seguindo o mesmo licenciamento do desenvolvimento contratado.
A estrutura, ou esquema, de banco de dados em si é outro objeto de
licenciamento em si. Não estamos falando dos dados que serão armazenados,
mas a forma que será armazenado. Fazendo uma analogia, os dados são a
carga de um contêiner, o esquema de dados é o contêiner em si, e o banco de
dados é o depósito onde estão todos os contêineres armazenados.
4.4.2. Elementos externos
Podemos considerar elementos externos as bibliotecas, framework,
documentação, e sons, vídeos e imagens. Vejamos cada um com mais cuidado.
4.4.2.1. Bibliotecas
As bibliotecas são códigos reutilizáveis organizado e simplificado para facilitar
a vida do programador. Um exemplo que ajuda a entender seu funcionamento
é uma biblioteca1 para validar CPF em Java.
1
http://javafree.uol.com.br/artigo/851371/Validacao-de-CPF.html (2012)
47 de 69
Aspectos legais no desenvolvimento de soluções de TI
/* ******************************************************
* Código Original:
* Autor: Allan Peron
* ******************************************************
* Modificações feitas para fácil aplicação
*/
package br.com.javafree.wscpf;
public abstract class CPF extends Object {
private static String calcDigVerif(String num) {
Integer primDig, segDig;
int soma = 0, peso = 10;
for (int i = 0; i < num.length(); i++)
soma += Integer.parseInt(num.substring(i, i + 1)) * peso--;
if (soma % 11 == 0 | soma % 11 == 1)
primDig = new Integer(0);
else
primDig = new Integer(11 - (soma % 11));
soma = 0;
peso = 11;
for (int i = 0; i < num.length(); i++)
soma += Integer.parseInt(num.substring(i, i + 1)) * peso--;
soma += primDig.intValue() * 2;
if (soma % 11 == 0 | soma % 11 == 1)
segDig = new Integer(0);
else
segDig = new Integer(11 - (soma % 11));
return primDig.toString() + segDig.toString();
}
private static int calcSegDig(String cpf, int primDig) {
int soma = 0, peso = 11;
for (int i = 0; i < cpf.length(); i++)
soma += Integer.parseInt(cpf.substring(i, i + 1)) * peso--;
soma += primDig * 2;
if (soma % 11 == 0 | soma % 11 == 1)
return 0;
else
return 11 - (soma % 11);
}
public static String geraCPF() {
String iniciais = "";
Integer numero;
for (int i = 0; i < 9; i++) {
numero = new Integer((int) (Math.random() * 10));
iniciais += numero.toString();
}
return iniciais + calcDigVerif(iniciais);
}
public static boolean validaCPF(String cpf) {
if (cpf.length() != 11)
return false;
}
String numDig = cpf.substring(0, 9);
return calcDigVerif(numDig).equals(cpf.substring(9, 11));
}
Código 2: Código Java para validação de CPF
Praticamente em qualquer sistema comercial tem a necessidade de se ter o
CPF1 dos clientes e é necessário fazer a validação deste para evitar erros
futuros no sistema contábil. Não há necessidade de reescrever o código cada
vez que se inicia um novo projeto, podendo simplesmente reaproveitar o
código, ou seja, fazer uma biblioteca na linguagem usada e reaproveitá-la em
novos projetos. Por isso é importante ter um licenciamento claro da biblioteca
e do projeto em si.
1
http://javafree.uol.com.br/artigo/851371/Validacao-de-CPF.html (2012)
48 de 69
Aspectos legais no desenvolvimento de soluções de TI
Um exemplo prático em relação a licenciamento é o desenvolvimento de um
sistema e utilizar bibliotecas fechadas. Ao utilizar uma biblioteca fechada é
importante analisar se o licenciamento permite a distribuição da mesma ou se
é necessário adquirir licenças adicionais. Em caso de uso destas bibliotecas
sem a devida regularização de uso pode acarretar em litígio contra a
empresa.
Outro exemplo é o uso de bibliotecas sob licenças abertas do tipo
protecionistas totais, como a GPL, que proíbem a sua distribuição com códigos
sob outros tipos de licenças. Na prática, se você utiliza uma biblioteca GPL,
terá que entregar o seu código sem a(s) referida(s) biblioteca(s) e dar as
orientações para que o cliente (ou quem irá instalar o sistema) baixe as
bibliotecas e as disponibilize no ambiente de produção.
4.4.2.2. Framework
Framework é similar a biblioteca no sentido de facilitar o trabalho do
programador. Se desenvolvermos um sistema web em Java, conectando em
um banco de dados Oracle®, geralmente utilizamos bibliotecas para conexão
entre o sistema e o banco de dados. No entanto, caso queiramos trocar de
banco de dados será necessário um retrabalho no código (refatoração) para
adaptar ao novo banco. Agora, se empregamos um framework, ele pode
oferecer uma abstração, facilitando uma troca de tecnologia como esta, pois o
framework já contempla esse processo dentro dele.
No entanto, como código, está sob uma determinada licença, como é o caso do
Demoiselle1, framework desenvolvido pelo SERPRO – Serviço Federal de
Processamento de Dados – para atender suas demandas de desenvolvimento
em Java. Este framework foi desenvolvido sob a licença LGPL (GNU Library or
Lesser General Public License v. 3.0). Esta licença é adequada tanto para
desenvolvimento de sistemas com licenças fechadas quanto abertas.
O uso de frameworks fechados entram na mesma situação das bibliotecas,
precisando analisar a licença e regularizar o uso. Em caso de não se encontrar
o licenciamento, segue a regra padrão de licença fechada.
4.4.2.3. Documentação
A documentação, tal como sons e imagens, difere de código, inclusive no
licenciamento. Para textos, sons e imagens existem uma gama de licenças
mais adequadas do que as licenças de software, como é o caso da Creative
1
http://www.frameworkdemoiselle.gov.br/ (2012)
49 de 69
Aspectos legais no desenvolvimento de soluções de TI
Commons2. Isso acontece porque as licenças se referem a código-fonte ou
objetos relacionados a engenharia de software.
Da Wikipédia, As licenças Creative Commons foram idealizadas para permitir a
padronização de declarações de vontade no tocante ao licenciamento e
distribuição de conteúdos culturais em geral (textos, músicas, imagens, filmes
e outros), de modo a facilitar seu compartilhamento e recombinação, sob a
égide de uma filosofia copyleft. As licenças criadas pela organização permitem
que detentores de copyright (isto é, autores de conteúdos ou detentores de
direitos sobre estes) possam abdicar em favor do público de alguns dos seus
direitos inerentes às suas criações, ainda que retenham outros desses direitos.
Isso pode ser operacionalizado por meio de um sortimento de módulos-padrão
de licenças, que resultam em licenças prontas para serem agregadas aos
conteúdos que se deseje licenciar.
Os módulos oferecidos podem resultar em licenças que vão desde uma
abdicação quase total, pelo licenciante, dos seus direitos patrimoniais, até
opções mais restritivas, que vedam a possibilidade de criação de obras
derivadas ou o uso comercial dos materiais licenciados. A documentação em si
pode estar em arquivos, como manuais em formato PDF, ou em wikis, sistema
colaborativo de conteúdo na web. Independente da forma que sejam
disponibilizados precisam ter seu licenciamento claro. De acordo a FSF 1 – Free
Software Foundation – em uma tradução livre:
Posso usar a GPL para algo diferente software?
Você pode aplicar a GPL para qualquer tipo de trabalho, desde que é
claro o que constitui o "código-fonte" para o trabalho. O GPL define isso
como a forma preferida do trabalho para fazer alterações nele. No
entanto, para manuais e livros didáticos, ou mais genericamente
qualquer tipo de trabalho que se destina a ensinar um assunto,
recomendamos o uso do GFDL – Gnu Free Documentation License - e não
a GPL.
Já do portal Creative Commons2:
Posso aplicar uma licença Creative Commons de software?
Nós não recomendamos. As licenças Creative Commons não devem ser
usadas para software. Nós encorajamos você a usar uma das muito boas
licenças de software disponíveis. Recomendamos as licenças
disponibilizadas pela Free Software Foundation ou listados no Open
2
1
2
http://www.creativecommons.org.br/ (2012)
http://www.gnu.org/licenses/gpl-faq.html#GPLOtherThanSoftware (2012)
http://wiki.creativecommons.org/FAQ#Can_I_apply_a_Creative_Commons_license_to_softwar
e.3F (2012)
50 de 69
Aspectos legais no desenvolvimento de soluções de TI
Source Initiative. Ao contrário das nossas licenças, que não fazem
menção ao código-fonte ou objeto, essas licenças existentes foram
projetadas especificamente para uso com software. Além disso, nossas
licenças não são compatíveis com a GPL, a licença de software mais
utilizadas gratuitamente.
4.4.2.4. Sons, vídeos e imagens
Da mesma forma que a documentação, esses elementos estão muito mais
associados a criações artísticas do que com software, de forma que se
enquadram na Lei de Direitos Autorais (Lei nº 9.610/98). O uso de elementos
com direito de propriedade de terceiros pode trazer um grande problema para
o cliente e a empresa.
Isso pode acontecer quando acontece o uso de imagens de pessoas, como
fotos, sem os devidos cuidados jurídicos, como cessão de direitos de imagem
para a empresa, ou ainda o uso de cliparts, sons, animações, etc., com os
mesmos cuidados ou a compra dos direitos de reprodução. Uma saída para
este tipo de problema é o uso destes elementos em Domínio Público ou
licença Creative Commons com permissão de trabalhos derivados ou uso
comercial.
Atualmente as principais ferramentas de busca, como o Google ou o Yahoo!,
contam com filtros de busca por licenciamento, o que ajuda muito na busca.
Outro repositório excelente é o projeto OpenCliparts.org, que serve de
repositório de trabalhos gráficos vetoriais em Domínio Público. Além disso,
temos ainda o portal governamental Domínio Público 1.
4.4.3. Declaração da licença
Este é um ponto importante do processo de geração do código pois a licença e
autoria devem estar presentes em cada arquivo-fonte. A inserção destes dados
pode ser feito durante o desenvolvimento, através do uso de modelos
(templates) com o cabeçalho pronto, ou ao final dele, adicionando em todos.
Cada licenciamento tem uma forma de especificar este cabeçalho. Vejamos a
seguir alguns dos principais.
1
http://www.dominiopublico.gov.br (2012)
51 de 69
Aspectos legais no desenvolvimento de soluções de TI
/*************************************************************************
<nome
da empresa ou cliente> - Todos os direitos reservados (c) ano
*
Licença,
referência adequada ao projeto ou arquivo da biblioteca ou
* ADOBEa CONFIDENTIAL
módulo
que pertence.
* __________________
Descrição
do que ela contém.
*
* [2002] - [2007] Adobe Systems Incorporated
História
* All Rights Reserved.
------*
2010/01/08
- Versão
inicial
- Programador
criação.
2010/01/09 * NOTICE: All
information
contained
herein is,
and remains
Programador
- Alterar
descrição
da versão.
* the property
of Adobe aSystems
Incorporated
and its suppliers,
* if any. The
intellectual- and
technical
concepts contained
2010/01/10
- Programador
Alterar
a descrição
da versão.
* herein are proprietary to Adobe Systems Incorporated
* and its suppliers
and3:may
be covered
by U.S.
and Foreign
Patents,
Código
Cabeçalho
de licença
fechada
genérica
* patents in process, and are protected by trade secret or copyright law.
* Dissemination of this information or reproduction of this material
* is strictly forbidden unless prior written permission is obtained
* from Adobe Systems Incorporated.
*/
Código 4: Cabeçalho de licença fechada da Adobe
Copyright (C) <year> <copyright holders>
/*
+-----------------------------------------------------------------------+
Permission
| program/include/rcube_browser.php
is hereby granted, free of charge, to any person obtaining a copy
|
of
| this software and associated documentation files (the "Software"), to deal
|
in
| the
ThisSoftware
file is without
part of restriction,
the Roundcubeincluding
Webmail client
without limitation the rights
|
to
| use,
Copyright
copy,(C)
modify,
2007-2009,
merge,The
publish,
Roundcube
distribute,
Dev Teamsublicense, and/or sell|
copies
| Licensed
of the
under
Software,
the GNU
and
GPL
to permit persons to whom the Software is
|
furnished
|
to do so, subject to the following conditions:
|
| PURPOSE:
|
The
| above
Classcopyright
representing
notice
theand
client
thisbrowser's
permission
properties
notice shall be included in
| all
copies
|
or substantial portions of the Software.
|
+-----------------------------------------------------------------------+
THE
| Author:
SOFTWARE
Thomas
IS PROVIDED
Bruederli
"AS<[email protected]>
IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
IMPLIED,
+-----------------------------------------------------------------------+
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS
$Id$
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*/
AUTHORS
OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER
INCabeçalho
AN ACTION de
OF licença
CONTRACT,
TORT
OR OTHERWISE,
ARISING FROM,
Código 5:
aberta
recíproca
total - GPL
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Código 4: Cabeçalho de licença aberta permissiva – MIT
52 de 69
Aspectos legais no desenvolvimento de soluções de TI
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -**
* ***** BEGIN LICENSE BLOCK *****
* Version: MPL 1.1/GPL 2.0/LGPL 2.1
*
* The contents of this file are subject to the Mozilla Public License Version
* 1.1 (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
* http://www.mozilla.org/MPL/
*
* Software distributed under the License is distributed on an "AS IS" basis,
* WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
* for the specific language governing rights and limitations under the
* License.
*
* The Original Code is JSIRC Library.
*
* The Initial Developer of the Original Code is
* New Dimensions Consulting, Inc.
* Portions created by the Initial Developer are Copyright (C) 1999
* the Initial Developer. All Rights Reserved.
*
* Contributor(s):
*
Robert Ginda, [email protected], original author
*
* Alternatively, the contents of this file may be used under the terms of
* either the GNU General Public License Version 2 or later (the "GPL"), or
* the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
* in which case the provisions of the GPL or the LGPL are applicable instead
* of those above. If you wish to allow use of your version of this file only
* under the terms of either the GPL or the LGPL, and not to allow others to
* use your version of this file under the terms of the MPL, indicate your
* decision by deleting the provisions above and replace them with the notice
* and other provisions required by the GPL or the LGPL. If you do not delete
* the provisions above, a recipient may use your version of this file under
* the terms of any one of the MPL, the GPL or the LGPL.
*
* ***** END LICENSE BLOCK ***** */
Código 5: Cabeçalho de licença aberta protecionista parcial - MPL
Por fim, com todos estes elementos explanados e discutidos, podemos ter uma
visão geral do processo sob o aspecto legal, resultado na figura abaixo.
Figura 35: Licenças presentes em um sistema computacional
53 de 69
Aspectos legais no desenvolvimento de soluções de TI
4.5. Registro
Este é um passo opcional. O registro de software pode ser considerado um
processo junto a um fiel depositário, que oferece o recurso de carimbo de
tempo sobre o mesmo. No Brasil, este processo fica a cargo do INPI – Instituto
Nacional de Propriedade Industrial. O processo é relativamente simples,
precisando gerar um arquivo em PDF de todo o código, gravar em um CD e
entregar este junto com a documentação solicitada para o processo,
devidamente descrito no portal da instituição 1. Além do registro junto ao INPI
tem outras vantagens, como o registro de marca, por exemplo.
Em caso de litígio, será esse carimbo de tempo a prova da originalidade. No
entanto, este não é o único processo aceito, podendo ser gravado um CD,
lacrado e postado para si mesmo, usando o carimbo de tempo do Correios
como prova temporal.
No caso de querer liberar o software como um software público, o registro no
INPI é parte obrigatória do processo.
4.6. Relações trabalhistas
Existe uma confusão quando tratamos dos direitos sobre o software, que
precisa de uma atenção especial para entender e diferenciar os diferentes
elementos que compõe este assunto. Uma coisa é o conhecimento do
programador sobre determinada tecnologia para desenvolver um algoritmo
que atenda as necessidades do cliente sob determinadas regras de negócio ou
intrínsecas ao ramo de negócio do cliente. Outra coisa é o produto gerado a
partir da união da necessidade do cliente, o conhecimento do programador, e
sua condição de empregado da empresa que o contratou para desenvolver
esta solução.
Sobre o conhecimento do programador, este é intrínseco a pessoa e/ou
empregado, pois o mesmo evolui no seu conhecimento através da experiência,
investimento em cursos, eventos, do dia a dia, etc. Neste foco, o direito de
autoria no desenvolvimento de uma solução de TI é intransferível e pertence a
ele.
Já pelo lado da empresa, é esta que faz a ponte entre o cliente e o
desenvolvedor, ou seja, é ela que traz o conhecimento, necessidades e regras
de negócios do cliente ou demanda do mercado para a produção da solução,
além de também ser responsável pela gestão do projeto/contrato, de integrar
diferentes profissionais de áreas distintas, bem como profissionais de
diferentes
áreas
dentro
do
TI
(como
arquitetura,
configuração,
desenvolvimento, qualidade, testes, especificação), criando uma coletividade
1
http://www.inpi.gov.br/index.php/programa-de-computador/guia-basico (2012)
54 de 69
Aspectos legais no desenvolvimento de soluções de TI
no desenvolvimento da solução. Além disso, esses profissionais são
contratados, seja por terceirização, seja por vínculo trabalhista, de forma que
estão
sendo
contratados
para
empregar
esse
conhecimento
no
desenvolvimento da solução, portanto garantindo a ela o direito de
propriedade ou copyright sobre o software desenvolvido em caso de se ter
desenvolvido a partir de uma demanda de mercado. Isso acontece
principalmente para os “softwares de prateleira”. Geralmente em caso de
contratos trabalhistas também estão inclusas cláusulas de confidencialidade
entre a empresa e o funcionário. Para o caso de terceirizações, as regras
devem estar devidamente registradas no contrato entre as partes.
E por fim, pelo lado do cliente existe o conhecimento do negócio, a
metodologia e a aplicabilidade deste conhecimento, que pode ser um
diferencial comercial e/ou estratégico desta frente ao mercado. Neste cenário,
geralmente é requerido um termo de confidencialidade entre cliente e
empresa. No caso de contratos de desenvolvimento entre cliente e empresa, o
direito de propriedade pertence ao cliente.
De acordo Tarcisio Queiroz Cerqueira1, programas de computador são
considerados, mundialmente, de maneira razoavelmente unânime, a despeito
de seu reconhecido caráter utilitário e das leis específicas que regulamentam
sua propriedade e comércio, bens intelectuais, equiparados a obras literárias,
científicas e artísticas, tais como livros, pinturas, música, fotografias, filmes,
gravações sonoras, etc.. Os programas são regulados e protegidos pelas leis da
Propriedade Intelectual. A Lei nº 9.610/98, nova Lei dos Direitos Autorais,
regulamenta os direitos autorais no Brasil, em acordo com a Constituição
Federal e com a Convenção de Berna, estabelecida em 1886, na Suíça, para
consolidar as regras mundiais acerca do "copyright" e dos direitos de autor,
atualizada de tempos em tempos e administrada pela OMPI/WIPO Organização Mundial da Propriedade Intelectual/World Intellectual Property
Organization, órgão da ONU, com sede em Genebra, da qual a quase totalidade
dos países do mundo é signatária. A Convenção de Berna foi concluída em 9 de
setembro de 1886, revista em Paris em 24/07/1971 e, através do Decreto nº
75.699, de 06/05/75, do então Presidente Ernesto Geisel, publicado no D.O.U.
de 09/05/75, passou a viger no Brasil. A Convenção de Berna encontra-se por
detrás de qualquer demanda judicial envolvendo "pirataria" de software, em
qualquer país do mundo. Antes de abordar direitos e deveres relacionados
com software ou com dados ou bases de dados ou informações, deve-se
considerar que a Lei dos Direitos Autorais (Lei nº 9.610, de 19/02/98)
estabelece, em seu Art. 4º, que "...Interpretam-se restritivamente os negócios
jurídicos sobre os direitos autorais", ou seja, não cabem, quanto aos direitos e
deveres relacionados com as obras protegidas, quaisquer interpretações legais
extensivas ou com auxílio de outro diploma legal, comparações ou adaptações:
1
http://www.tarcisio.adv.br/novo/index.php?pagina=lerartigo.php&id=24 (2012)
55 de 69
Aspectos legais no desenvolvimento de soluções de TI
vale apenas e unicamente o texto da lei, em sentido estrito. A Lei do Software
(Lei 9.609/98), que remete a proteção dos programas para os Direitos Autorais
(Lei 9.610/98) é clara em seu Art. 5º e define: software desenvolvido pelo
empregado pertence ao empregador. A determinação é justa, desde que o
empregado tenha sido designado para a função e receba remuneração para
tal. De acordo com a lei, somente a empresa poderá declarar-se titular dos
direitos de propriedade sobre programas de computador, o que inclui os
direitos de usar, licenciar, distribuir, vender, transferir ou comercializar de
qualquer forma ou modo. A legislação e a doutrina entendem que a
remuneração pelo salário remunera o empregado pelo seu trabalho, que, no
caso, é o de criar soluções em forma de programas de computador, a não ser
que contratos competentes estabeleçam o contrário.
56 de 69
Aspectos legais no desenvolvimento de soluções de TI
5. Outras considerações
Dentro do processo de desenvolvimento temos várias dúvidas de ordem
prática, como questões de compatibilidade entre licenças, a interpretação das
licenças no modelo jurídico brasileiro, responsabilidades dentro do
desenvolvimento de software, software para órgãos públicos e marcas.
Vejamos em mais detalhes estes pontos.
5.1. Licenças estrangeiras e a legislação brasileira
Do inglês: End User License Agreement (Licença do Usuário Final), ou
comumente conhecido como EULA, é o acordo entre desenvolvedor e usuário
onde se estabelece as regras para o uso e outras ações permitidas ou não,
relacionadas ao software. Para comercialização do produto no país é
necessário que a licença seja traduzida para o português, de acordo com a
exigência do art. 224 do Código Civil 1. Além deste dispositivo, temos ainda a
referência ao art. 9º da Lei 9.609/98 2, o qual estabelece o contrato de licença
como instrumento de regramento do uso de programas de computador no
Brasil, e em seu parágrafo único permite a substituição do instrumento de
contrato por documento fiscal, na hipótese de aquisição comercial do
programa como comprovação à aquisição ou licenciamento de cópia.
Em caso de produtos que não são vendidos, podendo ser os de licença do tipo
aberta ou fechada – gratuito ou adware - não há esta obrigação legal uma vez
que não existe comercialização.
Neste ponto, é importante salientar as diferenças das origens legais de cada
país, isto é, se o sistema legal local é de origem romano-germânica, com base
no sistema continental europeu, com o modelo baseado em leis escritas, ou do
sistema anglo-americano, baseado nas leis escritas e no senso comum da
sociedade, ou ainda chamado de Common Law.
As licenças estrangeiras, principalmente com redação no EUA são baseadas no
Common Law, e com foco no direito de cópia, ou copyright. Desta forma, trás
um agravante ainda maior ao processo de tradução, uma vez que a
interpretação sobre o produto software é diferente nos dois sistemas, um
tratando como obra artística e outro como objeto, no sistema brasileiro e
americano, respectivamente.
Devido a estes problemas, as entidades que desenvolveram as licenças, como
a Free Software Foundation entre outras, não reconhecem as traduções para
outros idiomas como legais. Apesar de haver uma série de traduções de
qualidade, apenas a GPL passou por um processo de análise jurídica feita pela
1
2
http://www.planalto.gov.br/ccivil_03/leis/2002/L10406.htm#prova (2012)
http://www.planalto.gov.br/ccivil_03/leis/L9609.htm (2012)
57 de 69
Aspectos legais no desenvolvimento de soluções de TI
Fundação Getúlio Vargas – FGV-Rio – e o projeto Creative Commons para uso
no projeto de Software Público Brasileiro, do Ministério do Planejamento,
criando a GLP-CC-V21. É importante observar que a GPLS-CC-V2 não é
reconhecida pela Free Software Foundation, de forma que deve ser
interpretada como outra licença. Da página da Free Software Foundation 2, em
tradução livre:
“A razão que o FSF não aprovar essas traduções como oficialmente válidas é
que verificá-las seria difícil e caro (necessitando a ajuda de advogados
bilíngues em outros países). Pior ainda, se um erro fosse inserido nelas, os
resultados poderiam ser desastrosos para toda a comunidade de software livre.
Enquanto as traduções não são oficiais, elas não podem fazer nenhum mal.”
Porém, o fato de não termos traduções sobre as licenças e muitos produtos
não serem comercializados não invalida os termos descritos na mesma, uma
vez que o licenciamento de software está sob o crivo do Acordo TRIPs 3 (TradeRelated Aspects of Intellectual Property Rights), que estende as regras para
todos os países signatários, entre eles o Brasil.
Não são poucos os casos de violação de licenças como a GPL, por exemplo, de
forma que surgiu inclusive projetos como o GPL-Violations 4, a qual dá suporte
jurídico em diferentes países pelo mundo sobre problemas com produtos
licenciados sob esta licença.
5.2. Compatibilidade de licenças
Uma dúvida frequente entre os desenvolvedores está no licenciamento de
soluções ou ainda no uso de diferentes componentes, com diferentes licenças,
na composição de uma solução aberta ou fechada. Vejamos as possibilidades,
abordando apenas as principais licenças:
1
2
3
4
http://www.softwarelivre.gov.br/Licencas/LicencaCcGplBr/ (2012)
http://www.gnu.org/licenses/old-licenses/gpl-2.0-translations.html (2012)
http://www.wto.org/english/docs_e/legal_e/27-trips_01_e.htm (2012)
http://gpl-violations.org/about.html (2012)
58 de 69
Aspectos legais no desenvolvimento de soluções de TI
Licença
Uso
Comercia Modificar Distribuir
individual lização
Binários
Créditos
Código
Fonte
Trocar
Licença
BSD
S
S
S
S
O
F
F
MIT
S
S
S
S
O
F
F
Apache
S
S
S
S
O
F
F
GPL
S
S
S
S
O
O
N
LGPL
S
S
S
S
O
O
N
MPL
S
S
S
S
O
O
F
CC
S
D
F
NA
O
F
N
DP
S
S
S
NA
F
F
F
P = permitido; O = obrigatório; F = facultativo; N = negado; NA = não aplicável; D = depende da licença
Tabela 4: Compatibilidade entre licenças
Como explica David A. Wheeler, em seu trabalho The Free-Libre / Open Source
Software (FLOSS) License Slide1, nem todas as licenças abertas são usadas, e
as licenças mais comuns tendem a serem compatíveis, ou seja, o software
pode ser combinado para produzir uma obra maior. A figura abaixo, inspirado
neste trabalho, foi feita uma expansão adicionando os demais tipos de licenças
e torna mais fácil de ver quando as licenças comuns podem ser combinadas.
Figura 36: Relação e compatibilidade entre as licenças
E na tabela abaixo, inspirado no trabalho de C. Chandam 2, compara os grupos
de licenças.
1
2
http://www.dwheeler.com/essays/floss-license-slide.html (2012)
https://blogs.oracle.com/chandan/entry/copyrights_licenses_and_cddl_illustrated (2012)
59 de 69
Aspectos legais no desenvolvimento de soluções de TI
Figura 37: Comparativo entre os tipos de licenças
60 de 69
Aspectos legais no desenvolvimento de soluções de TI
5.3. Responsabilidades dentro do desenvolvimento de
software
As penalidades por uso de software irregular dentro de uma empresa é a forma
mais comum de questões de litígio relacionados a programas de computador, e
cada vez é tratado com mais facilidade pela justiça brasileira, aja visto se
tratar de um assunto recorrente. Um exemplo extraído de: Direito Público - 28
de Fevereiro de 20111:
“Pirataria de software
A 4ª Turma do Superior Tribunal de Justiça (STJ) decidiu que a
indenização imposta ao infrator por uso sem licença de programa de
computador não se restringe ao valor de mercado dos produtos
apreendidos. De acordo com os ministros, a indenização por violação de
direitos autorais deve ser punitiva e seguir as regras do artigo 102 da Lei
nº 9.610, de 1998, que impõe maior rigor na repressão à prática de
pirataria. O entendimento, já adotado pela 3ª Turma do STJ, reformou
decisão do Tribunal de Justiça do Rio Grande do Sul (TJ-RS). Para o
tribunal local, na hipótese de apuração exata dos produtos falsificados, a
indenização se restringiria ao pagamento do preço alcançado pela
venda. No caso, o TJ-RS condenou uma empresa de bebidas a pagar à
Microsoft Corporation indenização por 28 cópias de softwares
apreendidos. Os magistrados se basearam no artigo 103 da Lei de
Direitos Autorais. A Microsoft recorreu, então, ao STJ. Para os ministros, a
interpretação adotada pelo TJ-RS apenas remunera pelo uso ilegal do
programa, mas não indeniza a proprietária do prejuízo sofrido. Na
ausência de dispositivo expresso sobre a matéria, decidiram aplicar o
entendimento do artigo 102 da Lei nº 9.610, que estabelece indenização
no caso de fraude.
Valor Econômico”
De acordo com a Business Software Aliance – BSA, existem cinco tipos comuns
de pirataria de software2, a saber:
1
2
•
Pirataria do usuário final;
•
Superutilização de cliente-servidor;
•
Pirataria na Internet;
•
Falsificação de software
http://direito-publico.jusbrasil.com.br/noticias/2586041/pirataria-de-software (2012)
http://www.bsa.org/country/Anti-Piracy/What-is-Software-Piracy/Types%20of%20Piracy.aspx
(2012)
61 de 69
Aspectos legais no desenvolvimento de soluções de TI
Em caso de litígio, a empresa é responsável pelo problema de pirataria, mesmo
tendo área técnica específica, recaindo sobre seus representantes legais as
penalidades, mesmo que estes não tenham parte efetiva no uso ou difusão
interna dos softwares, pois é a empresa q tem a responsabilidade em fiscalizar
e escolher (in vigilandum et in eligendum) seus empregados, assumindo o total
risco do negócio.
Porém, é conveniente incluir no contrato de trabalho de seus empregados uma
cláusula sobre procedimentos internos sobre uso irregular de software,
atribuindo corresponsabilidade do empregado em caso deste tipo de
ocorrência. Esta ação não isenta a empresa da responsabilidade, mas esta é
mitigada com seus contratados em caso de uso indevido de software.
?
Figura 38: Litígio - responsabilidades internas e externas
A partir destas considerações, podemos mergulhar ainda mais nas questões
legais envolvendo o desenvolvimento de software, analisando um caso
hipotético que ilustra estes pontos em um caráter prático.
Pensemos o desenvolvimento de um sistema comercial de frente de caixa, isto
é, aqueles sistemas utilizados por comércio em geral, com cadastro de
produtos, clientes, venda e estoque. Pela análise da arquitetura, pode ser
orientado a web, feito em Java, com banco de dados MySQL. Uma vez
aprovado o orçamento, se inicia os trabalhos realizando as tarefas como
gestão do projeto, levantamento de requisitos, e outras ações já citadas. Em
caso de se utilizar softwares para estas atividades estamos falando
necessariamente de licenças de uso, que podem ser pagas para os de licença
fechada, ou gratuitas em caso de licenças abertas. Como comentado acima, é
necessário estar em situação regular.
62 de 69
Aspectos legais no desenvolvimento de soluções de TI
Aprofundando um pouco mais no lado técnico, a linguagem de programação
elegida foi o Java. Geralmente para tornar o desenvolvimento mais ágil,
fazemos uso de frameworks. A linguagem Java conta com um grande número
de frameworks, inclusive com frameworks desenvolvidos pela própria empresa.
Considerando que seja usado o desenvolvido internamente, se não há
explicitamente o licenciamento, estamos falando de um produto fechado, ou
ainda, com copyright.
Ainda com a linguagem Java, pode são utilizados um grande volume de
biblioteca de terceiros. No nosso caso hipotético, vamos considerar alguns tais
como:
•
Dbbrowser1 – Gnu General Public License (GPL) – navegador de dados;
•
Strings2 - Apache Public License (APL) - framework para infraestrutura e
serviço de dados;
•
Crystal Reports3 - Licença própria da SAP (EULA) – ferramentas para
geração de relatórios.
A escolha destas bibliotecas se deu dentro da fábrica de software, na equipe
de programadores. Linguagem e banco de dados, foi escolha da arquitetura. O
desenvolvimento transcorreu normalmente, gerando a aplicação do cliente,
passando pelos testes e homologação, finalmente sendo entregue para o
cliente, confirmado pelo termo de aceite, a aplicação (instalador),
documentação e código-fonte, além de passos adicionais para implantação do
sistema no ambiente de produção nos servidores do cliente.
Acontece que desta forma, o produto encontra-se com várias irregularidades.
Vejamos o que acontece.
1
2
3
•
Banco de dados: o MySQL possui licença comercial com cláusula de
exceção FOSS (Free and Open Source Software). Como a aplicação não é
de código aberto, então precisa ser comprada as licenças necessárias;
•
Dbbrowser: Como se trata de um componente GPL, e de acordo essa
licença só pode ser distribuído com componentes GPL e/ou bibliotecas
LGPL, torna-se incompatível com o sistema, pois transgride as regras
estabelecidas na licença;
•
Springs: Este é um ótimo exemplo de produto com licença permissiva,
que permite esta distribuição casada, ou ainda, trocar a licença do
componente, adequando-o ao produto;
http://java-source.net/open-source/sql-clients/dbbrowser
http://www.springsource.org/
http://crystalreports.com/
63 de 69
Aspectos legais no desenvolvimento de soluções de TI
•
Crystal Reports: a empresa não comprou licenças para seu uso. Os
desenvolvedores buscaram por outros meios uma cópia para atender a
demanda de relatórios do sistema. Ao final, foi empacotado junto, como
parte da solução.
•
Framework: caso o cliente queira distribuir ou trocar a licença do
software desenvolvido, terá problemas graves pela dependência do
licenciamento do framework empregado, que tem o direito autoral
pertencente à fábrica de software.
Considerando que o software fosse distribuído, precisaríamos ajustar todos os
pontos acima para evitar um processo jurídico. Uma vez que é constatado
violação de algum tipo, o cliente pode mover uma ação contra a fábrica de
software em relação ao desenvolvimento em si, e outro por danos morais.
Como explicado anteriormente, a empresa é responsável integralmente pelo
ônus, mas como pudemos ver, podem existir várias ações internas de
penalização dos diversos atores do processo de desenvolvimento, dependendo
das regras estabelecidos no contrato trabalhista.
No caso do banco de dados, seria necessário avaliar quem estabeleceu esse
componente, e de quem seria a função de avaliar se as licenças estão
disponíveis e se seriam compatíveis com a licença final do produto. Da mesma
forma, o uso de componentes, como as bibliotecas, tangem à equipe de
programadores. As licenças foram respeitadas? A inserção de produtos com
licenças fechadas era de ciência de todos? Do gerente de projeto? Da diretoria
de desenvolvimento? Dependendo das respostas, são imputadas as
corresponsabilidades e aplicada as devidas sansões, que pode ser desde
advertências até demissão.
5.4. Software para órgãos públicos – aquisição e
desenvolvimento
No Programa de Governo Eletrônico, desenvolvido pelo Ministério do
Planejamento, do Governo Brasileiro, foram desenvolvidos uma série de ações
das quais podemos citar algumas como:
•
Padrões de Interoperabilidade de Governo Eletrônico1 – E-Ping
define um conjunto mínimo de premissas, políticas e especificações
técnicas que regulamentam a utilização da Tecnologia de Informação e
Comunicação (TIC) no governo federal, estabelecendo as condições de
interação com os demais Poderes e esferas de governo e com a
1
http://www.governoeletronico.gov.br/acoes-e-projetos/e-ping-padroes-de-interoperabilidade
(2012)
64 de 69
Aspectos legais no desenvolvimento de soluções de TI
sociedade em geral. Para os órgãos do governo federal – Poder
Executivo brasileiro a adoção dos padrões e políticas contidos na e-PING
é obrigatória (Portaria SLTI/MP nº 5, de 14 de julho de 20051).
•
Modelo de Acessibilidade de Governo Eletrônico2 – e-MAG
O Modelo de Acessibilidade de Governo Eletrônico consiste em um
conjunto de recomendações a ser considerado para que o processo de
acessibilidade dos sítios e portais do governo brasileiro seja conduzido
de forma padronizada e de fácil implementação.
•
Software Público3
é um ambiente para gestão das soluções desenvolvidas na
Administração Pública compartilhando ferramentas que podem ser úteis
aos mais diferentes órgãos públicos e também à sociedade. O objetivo é
reduzir
custos,
aprimorar
os
aplicativos
disponibilizados
e,
consequentemente, melhorar o atendimento à população. (Portaria
SLTI/MP nº 1, de 17 de janeiro de 2011).
Além disso, pela Instrução Normativa Nº 04, de 12 de novembro de 2010, em
seu Art. 11, cita (com grifos por conta do autor para destacar):
Art. 11. A Análise de Viabilidade da Contratação será realizada pelos
Integrantes Técnico e Requisitante, compreendendo as seguintes tarefas:
(…)
II - identificação das diferentes soluções que atendam aos requisitos,
considerando:
a) a disponibilidade de solução similar em outro órgão ou entidade da
Administração Pública;
b) as soluções
Brasileiro;
existentes
no
Portal
do
Software
Público
c) a capacidade e alternativas do mercado, inclusive a existência
de software livre ou software público;
d)
a observância às políticas, premissas e especificações
técnicas definidas pelos Padrões de Interoperabilidade de
Governo Eletrônico - e-PING e Modelo de Acessibilidade em
1
2
3
http://www.governoeletronico.gov.br/o-gov.br/legislacao/portaria-no-05-de-14-de-julho-de2005 (2012)
http://www.governoeletronico.gov.br/acoes-e-projetos/e-MAG (2012)
http://www.governoeletronico.gov.br/acoes-e-projetos/software-livre/portal-do-softwarepublico (2012)
65 de 69
Aspectos legais no desenvolvimento de soluções de TI
Governo Eletrônico – e-MAG, conforme as Portarias Normativas
SLTI no 5, de 14 de julho de 2005, e no 3, de 7 de maio de 2007;
E ainda, sobre a questão de contratação por órgãos
desenvolvimento de software, citamos o Art. 27 da referida IN:
públicos
para
Art. 27. Os softwares resultantes de serviços de desenvolvimento
deverão ser catalogados pela contratante e, sempre que aplicável,
disponibilizados no Portal do Software Público Brasileiro de acordo com o
regulamento do Órgão Central do SISP.
Em caso de se tratar de uma empresa pública que adquire o software passa a
ser obrigada a verificar estes e outros pontos definidos nos respectivos
dispositivos normativos, e quem desenvolve, passa a ter uma preocupação a
mais para garantir a compatibilidade de seus sistemas a essas novas
condições.
5.5. A marca
A marca de um produto geralmente tem uma política de licenciamento
diferente do software em si. Para ilustrar melhor esse detalhe, vejamos dois
exemplos: Mozilla Firefox e Google Chrome.
Mozilla Firefox é um navegador web desenvolvido pela Mozilla Foundation com
colaboração de desenvolvedores de todo o mundo. O código-fonte está
licenciado sob a Mozilla Public License – MPL, que é uma licença aberta e,
assim, com o código-fonte disponível, porém código-fonte não significa o
programa que estamos acostumados a usar. Para chegar lá é necessário
executar um processo chamado compilação, que consiste na conversão deste
código para o programa em si, também chamado de binário, que é o que ao
final usamos. No caso do Mozilla Firefox, que tem este nome e um logotipo
associado só pode ser empregado em binários gerados pela própria Mozilla
Foundation. Caso seja feita por outra instituição, eles se reservam ao direito de
não autorizar o uso do nome. Isso faz sentido se pensar que qualquer pessoa,
com o devido conhecimento técnico e ferramentas adequadas, pode modificar
o código, compilar e distribuir os binários. Caso aconteça algum problema, a
culpa não pode ser repassada a Mozilla Foundation. Assim, ainda é possível
gerar binários, mas terá que ser com outro nome. Isso aconteceu dentro da
distribuição Linux chamada Debian1, que precisou trocar o nome e o logotipo
do navegador compilado por eles.
Ainda sobre o Mozilla Firefox ocorreu uma nova ocorrência com a criação do
projeto WaterFox, que busca compilar um navegador que utilize os novos
1
http://www.debian.org (2012)
66 de 69
Aspectos legais no desenvolvimento de soluções de TI
recursos de 64bits dos novos sistemas operacionais da Microsoft, o Windows
Vista 64bits e o Windows 7 64bits.
Figura 39: Derivação de marcas a partir do produto Mozilla Firefox
Outro exemplo é do navegador web Google Chrome, que é derivado do projeto
Chromium1, que tem a proposta de construir um navegador web de código
aberto rápido, seguro e mais estável. Assim, o Google investe esforços no
desenvolvimento deste projeto e seu time de desenvolvedores geram binários
periodicamente sob suas especificações. Este produto chama-se Google
Chrome, caso contrário, deve se chamar Chromium, ou em outra forma, se é
Google Chrome, é feito (compilado) pela Google, se não, é feito por
desenvolvedores independentes.
Figura 40: Troca de logo de Chromium para Google Chrome
Ainda sobre marcas, é importante salientar que temos dispositivos legais para
tratar deste assunto, através da lei 9.279/96 2, que regula direitos e obrigações
relativos à propriedade industrial, no seu Título III.
1
2
http://www.chromium.org/Home
http://www.planalto.gov.br/ccivil_03/leis/L9279.htm
67 de 69
Aspectos legais no desenvolvimento de soluções de TI
5.6. Fluxograma operacional de análise legal para
desenvolvimento
Para consolidar todos os conceitos discutidos até aqui, foram sintetizados no
quadro abaixo.
Figura 41: Fluxo de análise de restrições e correções
68 de 69
Aspectos legais no desenvolvimento de soluções de TI
6. Material complementar
Para ajudar a compreender as questões de licenciamento de software, é
necessário entender a evolução do software e, por consequentemente, a
história da informática/computação em geral. Abaixo, seguem alguns materiais
que ajudam a conhecer estes elementos.
6.1. Filmes
6.1.1. Piratas do Vale do Silício (1999)
95 min - Biografia | Drama - 1 agosto de 1999 (Brasil)
Diretor: Martyn Burke
Escritor: Paul Freiberger (livro), Michael Swaine (livro),
Martyn Burke
Atores: Anthony Michael Hall, Noah Wyle e Joey Slotnick
IMDb: http://www.imdb.com/title/tt0168122/
6.1.2. Revolution OS (2001)
85 min - Documentario | Comédia
(EUA)
- 15 Fevereiro de 2002
Etiquetas: Hackers, Programmers & Rebels UNITE!
Diretor: J.T.S. Moore
Escritor: J.T.S. Moore
Atores: Linus Torvalds, Richard M. Stallman and Eric
Raymond
IMDb: http://www.imdb.com/title/tt0308808/
69 de 69
Aspectos legais no desenvolvimento de soluções de TI