Uma ferramenta para verificação de compatibilidade entre licenças de software

V´ıtor M´arcio Paiva de Sousa Baptista

Uma ferramenta para verificac¸a˜ o de compatibilidade entre licenc¸as de software

Jo˜ao Pessoa – PB Dezembro / 2010

V´ıtor M´arcio Paiva de Sousa Baptista

Uma ferramenta para verificac¸a˜ o de compatibilidade entre licenc¸as de software Monografia apresentada ao Curso de Bacharelado em Ciˆencia da Computac¸a˜ o da Universidade Federal da Para´ıba, em comprimento as exigˆencias para obtenc¸a˜ o do t´ıtulo de Bacharel em Ciˆencia da Computac¸a˜ o.

Orientador:

Prof. Me. Raoni Kulesza

˜ BACHALERADO EM C I Eˆ NCIA DA C OMPUTAC¸ AO ´ D EPARTAMENTO DE I NFORM ATICA C ENTRO DE C I Eˆ NCIAS E XATAS E DA NATUREZA U NIVERSIDADE F EDERAL DA PARA´I BA

Jo˜ao Pessoa – PB Dezembro / 2010

Este trabalho est´a licenciado sob a Creative Commons Atribuic¸a˜ o 3.0. http://creativecommons.org/licenses/by/3.0/

Monografia sob o t´ıtulo “Uma ferramenta para verificac¸a˜ o de compatibilidade entre licenc¸as de software”, defendida por V´ıtor M´arcio Paiva de Sousa Baptista:

Prof. Ma. Raoni Kulesza Departamento de Inform´atica - UFPB Orientador

Prof. Dr. Guido Lemos de Souza Filho Departamento de Inform´atica - UFPB Examinador

Prof. Ma. Alan Kelon Oliveira de Moraes Departamento de Inform´atica - UFPB Examinador

Agradecimentos O desenvolvimento deste trabalho n˜ao seria poss´ıvel sem o apoio direto e indireto de dezenas de pessoas. Mesmo me esforc¸ando ao m´aximo, n˜ao conseguiria citar todos. Entretanto, esta e´ uma singela forma de dizer “obrigado.” A minha fam´ılia, em especial minha m˜ae, av´o, avˆo, tia e madrinha, pelos 24 anos de suporte, carinho e amor, fundamentais para minha formac¸a˜ o como ser humano. A Samara, por todas as noites bem dormidas preenchidas de samba e amor. Aos meus amigos e amigas Maristella, Luana, Fernando, Pedro, Joseph, Anahuac, Rodrigo e tantos outros que, concientemente ou n˜ao, foram fundamentais nessa e em todas as outras etapas de minha vida. Em especial aos meus amigos de infˆancia Diego, Elias, Gustavo, Barreto, Carlos e Pl´acido, com quem tive a sorte de poder compartilhar as coisas boas (e ruins) da nossa adolescˆencia. Ao professor Raoni Kulesza, pelos anos de orientac¸a˜ o e incentivo. Minha formac¸a˜ o acadˆemica seria muito menos rica seu sua participac¸a˜ o. Ao professor Guido Lemos, pela mir´ıade de ideias que, apesar de mirabolantes, sempre se provaram corretas no final. Ao professor Alan Kelon, pelas diversas e engrandecedoras discuss˜oes, e pelo seu empenho na melhoria do Departamento de Inform´atica da UFPB. A todos professores e professoras do Departamento de Inform´atica da Universidade Federal da Para´ıba, em especial ao professor Hamilton Soares, que n˜ao se contentando em serem somente mestres, viraram amigos. A Simone, sem cuja ajuda eu, e todos outros alunos de Computac¸a˜ o, ter´ıamos muito mais dores de cabec¸a em todos in´ıcios de per´ıodo, nas matr´ıculas.

“Geeks like to think that they can ignore politics, you can leave politics alone, but politics won’t leave you alone.” Richard M. Stallman

Resumo Atualmente, e´ crescente a adoc¸a˜ o do paradigma de desenvolvimento distribu´ıdo de software, onde empresas em localidades distintas trabalham para a criac¸a˜ o de um produto. Isto diminui os custos e tempo de produc¸a˜ o e aumenta a qualidade dos sistemas criados, mas pode gerar problemas com relac¸a˜ o aos direitos autorais dos criadores de cada parte do software. O autor tem direito exclusivo ao usufruto de sua obra por um tempo pr´e-determinado. Ele pode ceder parte desses direitos a terceiros atrav´es de um contrato de licenc¸a, onde define o que pode e o que n˜ao se pode fazer com sua criac¸a˜ o. Inclusive, pode restringir o gozo dessas permiss˜oes a alguma condic¸a˜ o. Quando usa-se softwares com partes de diversos autores, faz-se necess´ario conhecer o conjunto de permiss˜oes, restric¸o˜ es e proibic¸o˜ es da licenc¸a de cada uma, para garantir que todas sejam respeitados. Este processo e´ chamado de verificac¸a˜ o de compatibilidade entre licenc¸as de software. Falhar nele pode trazer preju´ızos financeiros atrav´es de processos judiciais contra a empresa. Este trabalho apresenta uma ferramenta, o licc, desenvolvida para automatizar esse processo de verificac¸a˜ o de compatibilidade. Para isto ela utiliza-se de linguagem de express˜ao de direitos, a ccREL, que define um conjunto de atributos de licenc¸as. A partir deles, ela indica se duas ou mais licenc¸as s˜ao compat´ıveis ou n˜ao. Palavras-chave: Licenc¸as de software. Compatibilidade entre licenc¸as de software. Linguagens de descric¸a˜ o de direitos. ccREL. Desenvolvimento distribu´ıdo de software.

Abstract Nowadays, the adoption of the distributed software development, where companies in different places work together in the creation of a product. This lessen the costs and development time and increases the quality of the developed software, but might create problems related to the copyright of each product part’s author. The authors have exclusive rights to benefit from their creations for a limited amount of time. He can allow the usage of these rights by others using a license contract, a legal instrument where he defines the permissions, prohibitions and restrictions to his creation use. When software with many parts authored by different people, it’s needed to know by which terms you are allowed to use each part, to guarantee that all are respected. This process is named software license compatibility verification. Failing in it might result in economical losses by being sued by its authors. This work presents a tool, licc, developed to automatize this process of verification of compatibility. For such, it uses a rights expression language, ccREL, which defines a set of license’s attributes, from which it checks if two or more licenses are compatible or not. Keywords: Software licenses. Software licenses compatibility. Rights expression languages. ccREL. Distributed software development.

Lista de Figuras 2.1

Divis˜ao da Propriedade Intelectual no Brasil . . . . . . . . . . . . . . . . . .

p. 18

2.2

Tipos de Licenc¸as de Software Livre . . . . . . . . . . . . . . . . . . . . . .

p. 24

2.3

Relicenciamento com sucesso . . . . . . . . . . . . . . . . . . . . . . . . .

p. 31

2.4

Relicenciamento falho . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 31

2.5

Relicenciamento falho por restric¸o˜ es nas licenc¸as . . . . . . . . . . . . . . .

p. 32

2.6

Combinac¸a˜ o com c´odigo LGPL . . . . . . . . . . . . . . . . . . . . . . . .

p. 33

2.7

Combinac¸a˜ o com sucesso entre licenc¸as BSD, LGPL e CDDL . . . . . . . .

p. 34

2.8

Combinac¸a˜ o falha entre licenc¸as BSD, GPL e CDDL . . . . . . . . . . . . .

p. 35

3.1

Fluxograma de compatibilidade de relicenciamento . . . . . . . . . . . . . .

p. 37

3.2

Fluxograma de compatibilidade de combinac¸a˜ o . . . . . . . . . . . . . . . .

p. 39

4.1

Diagrama de caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 43

4.2

Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 44

5.1

Tela do GingaInstancing mostrando que h´a uma incompatibilidade entre as licenc¸as dos componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 49

Lista de Tabelas 2.1

Diferenc¸as entre Direito Autoral e Propriedade Industrial . . . . . . . . . . .

p. 19

2.2

Atributos definidos pelo ccREL . . . . . . . . . . . . . . . . . . . . . . . . .

p. 28

2.3

Licenc¸as descritas com o ccREL . . . . . . . . . . . . . . . . . . . . . . . .

p. 29

4.1

Compatibilidade de relicenciamento entre as licenc¸as . . . . . . . . . . . . .

p. 46

4.2

Compatibilidade de combinac¸a˜ o entre as licenc¸as . . . . . . . . . . . . . . .

p. 47

Lista de Abreviaturas e Siglas BY Atribuic¸a˜ o CC Creative Commons CDC C´odigo de Defesa do Consumidor ccREL Creative Commons’s Rights Expression Language DDS Desenvolvimento Distribu´ıdo de Software DRM Digital Rights Management FSF Free Software Foundation GNU GNU’s Not Unix GPL GNU General Public License INPI Instituto Nacional de Propriedade Intelectual LGPL GNU Lesser General Public License LICC License Compatibility Checker NC Uso n˜ao-comercial ND Vedada a criac¸a˜ o de obras derivadas OMPI Organizac¸a˜ o Mundial de Propriedade Intelectual PD Dom´ınio P´ublico RDF Resource Description Framework REL Rights Expression Language SA Share Alike WIPO Word Intellectual Property Organization XML eXtensible Markup Language

Sum´ario

1

2

Introduc¸a˜ o

p. 14

1.1

Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 15

1.2

Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 15

Fundamentac¸a˜ o Te´orica

p. 16

2.1

Propriedade Intelectual . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 16

2.2

Direitos Autorais e Propriedade Industrial . . . . . . . . . . . . . . . . . . .

p. 17

2.3

O Software e a Propriedade Intelectual no Brasil . . . . . . . . . . . . . . . .

p. 19

2.4

Software Livre e Software Propriet´ario . . . . . . . . . . . . . . . . . . . . .

p. 22

2.5

Licenc¸as de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 22

2.6

Licenc¸as de Software Livre . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 23

2.6.1

Permissivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 23

2.6.1.1

BSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 24

2.6.1.2

X11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 24

Copyleft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 24

2.6.2.1

GNU General Public License (GPL) . . . . . . . . . . . .

p. 25

Lesser Copyleft . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 25

2.6.3.1

GNU Lesser General Public License (LGPL) . . . . . . . .

p. 25

2.6.3.2

Common Development and Distribution License (CDDL) .

p. 25

Share Alike . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 26

2.6.4.1

Attribution-ShareAlike (BY-SA) . . . . . . . . . . . . . .

p. 26

Linguagens de Express˜ao de Direitos . . . . . . . . . . . . . . . . . . . . . .

p. 26

2.6.2

2.6.3

2.6.4

2.7

2.7.1 2.8

3

6

Compatibilidade entre Licenc¸as de Software . . . . . . . . . . . . . . . . . .

p. 28

2.8.1

Relicenciamento . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 30

2.8.2

Combinac¸a˜ o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 33 p. 36

3.1

Relicenciamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 36

3.1.1

BSD → GPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 36

3.1.2

GPL → BSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 38

Combinac¸a˜ o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 38

3.2.1

BSD e GPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 39

3.2.2

BY e BY-ND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 40

Compatibilidade entre mais de duas licenc¸as . . . . . . . . . . . . . . . . . .

p. 40

3.3

5

p. 27

Modelo de verificac¸a˜ o de compatibilidade entre licenc¸as de software

3.2

4

Creative Commons Rights Expression Language – ccREL . . . . . .

License Compatibility Checker (licc)

p. 41

4.1

Cen´arios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 41

4.1.1

Cen´ario 1: Samara . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 41

4.1.2

Cen´ario 2: Dione . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 41

4.1.3

Cen´ario 3: Nath´alia . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 42

4.2

Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 42

4.3

Requisitos N˜ao-Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 43

4.4

Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 43

4.5

Validac¸a˜ o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 45

Estudo de Caso

p. 48

5.1

p. 48

GingaInstancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Trabalhos Relacionados

p. 50

7

6.1

Black Duck TM Protex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 50

6.2

Librock License Awareness System – Lidesc . . . . . . . . . . . . . . . . . .

p. 50

Conclus˜ao

p. 51

7.1

p. 52

Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Referˆencias Bibliogr´aficas

p. 53

Gloss´ario

p. 56

14

1

Introduc¸a˜ o

O desenvolvimento de softwares se d´a cada vez mais em um ambiente distribu´ıdo, onde diversas empresas, em localidades diferentes, trabalham para a criac¸a˜ o de um produto [1]. Estas empresas n˜ao tem necessariamente conhecimento uma da outra, pois uma pode simplesmente usar um componente j´a criado e disponibilizado na Internet como Software Livre [2]. Esse ambiente de desenvolvimento distribu´ıdo pode ser muito vantajoso para todos os participantes, diminuindo custos e tempo de produc¸a˜ o e, ao mesmo tempo, aumentando a qualidade dos sistemas criados [3]. Entretanto, deve haver uma precauc¸a˜ o com relac¸a˜ o aos direitos dos autores de cada parte [3] [2]. Cada autor pode definir de que formas permitem que seus softwares sejam utilizados [4]. E, ao unir diversos produtos de autores distintos, a empresa deve se certificar que essas formas n˜ao sejam conflitantes nem entre si, nem com a licenc¸a do sistema como um todo [3] [2]. Este processo e´ a verificac¸a˜ o de compatibilidade entre licenc¸as de software. Ele se divide em dois tipos: relicenciamento e combinac¸a˜ o. O primeiro ocorre quando tem-se um projeto com diversas partes sob licenc¸as distintas e se quer licenciar o todo sob uma outra. J´a o segundo ocorre quando tem-se esse mesmo projeto, mas n˜ao se deseja colocar o produto final sob uma licenc¸a u´ nica. Ao final, ele ser´a composto por v´arias partes, cada qual sob sua licenc¸a independente. Este trabalho prop˜oe-se a apresentar uma forma de facilitar esse processo atrav´es do desenvolvimento de uma ferramenta para auxiliar a automatizac¸a˜ o da verificac¸a˜ o da compatibilidade entre licenc¸as de software – o licc. Ela foi validada com relac¸a˜ o a an´alises de compatibilidade feitas por funcion´arios da Creative Commons de Taiwan e pela Free Software Foundation [5] [6], e foi feito um estudo de caso sobre a ferramenta GingaInstancing que usa o licc para implementar sua funcionalidade de verificac¸a˜ o de compatibilidade.

1.1 Objetivos

1.1

15

Objetivos

O objetivo principal deste trabalho e´ desenvolver uma ferramenta capaz de detectar incompatibilidades entre licenc¸as de software, tanto com relac¸a˜ o a combinac¸a˜ o quanto ao relicenciamento. Como objetivos espec´ıficos, temos: • Propˆor modelo de verificac¸a˜ o de compatibilidade entre licenc¸as de software; • Desenvolver ferramenta capaz de verificar compatibilidade entre duas ou mais licenc¸as; • Criar uma su´ıte de testes para validar este algoritmo com relac¸a˜ o a compatibilidade entre licenc¸as j´a conhecidas.

1.2

Estrutura do Trabalho

Al´em deste primeiro cap´ıtulo de introduc¸a˜ o, o trabalho conta com seis outros. O cap´ıtulo segundo consiste na fundamentac¸a˜ o te´orica de temas relacionados ao direito autoral, propriedade intelectual, software livre e propriet´ario, licenc¸as de software e linguagens de express˜ao de direitos (REL 1 ) e compatibilidade entre licenc¸as de software. O terceiro cap´ıtulo apresenta o modelo proposto para verificac¸a˜ o de compatibilidade entre licenc¸as de software. O quarto apresenta a especificac¸a˜ o da ferramenta desenvolvida: o License Compatibility Checker – licc. O quinto cap´ıtulo consiste de um estudo de caso do uso do licc em uma ferramenta do projeto GingaCDN, para garantir a compatibilidade entre as licenc¸as dos componentes do Ginga, o middleware brasileiro de TV Digital. O pen´ultimo cap´ıtulo apresenta os trabalhos relacionados e, por fim, o u´ ltimo cap´ıtulo exp˜oe as considerac¸o˜ es finais e os poss´ıveis trabalhos futuros.

1 Rights

Expression Language

16

2

Fundamentac¸a˜ o Te´orica

2.1

Propriedade Intelectual

A Declarac¸a˜ o Universal dos Direitos do Homem, aprovada pela Assembl´eia Geral da ONU 1 em dezembro de 1948, traz em seu artigo 27 o seguinte texto: 1. Todo homem tem o direito de participar livremente da vida cultural da comunidade, de fruir as artes e de participar do progresso cient´ıfico e de seus benef´ıcios. 2. Todo homem tem direito a` protec¸a˜ o dos interesses morais e materiais decorrentes de qualquer produc¸a˜ o cient´ıfica, liter´aria ou art´ıstica da qual seja autor.

Neste contexto, surge o conceito de propriedade intelectual, tendo como premissa ontol´ogica “a ideia de que o homem usa sua capacidade criativa para se desenvolver e progredir” [7]. Ao se reconhecer o direito de propriedade sobre uma obra ou invenc¸a˜ o, protege-se o interesse da pr´opria sociedade, estimulando novas obras art´ısticas e cient´ıficas para que toda a sociedade possa delas usufruir. Em 1967 criou-se, no aˆ mbito das Nac¸o˜ es Unidas, a Organizac¸a˜ o Mundial da Propriedade Intelectual, mais conhecida por sua sigla em inglˆes, WIPO2 . Este o´ rg˜ao re´une as Uni˜oes de Paris e Berna (institu´ıdas por dois acordos internacionais distintos), e cuida da administrac¸a˜ o de v´arios outros tratados sobre propriedade intelectual. A Convenc¸a˜ o da OMPI definiu a Propriedade Intelectual como [8]: “(...) a soma dos direitos relativos a` s obras liter´arias, art´ısticas e cient´ıficas, a` s interpretac¸o˜ es dos artistas int´erpretes e a` s execuc¸o˜ es dos artistas executantes, aos fonogramas e a` s emiss˜oes de radiodifus˜ao, a` s invenc¸o˜ es em todos os dom´ınios da atividade humana, a` s descobertas cient´ıficas, aos desenhos e modelos industriais, comerciais e de servic¸o, bem como a` s firmas comerciais e denominac¸o˜ es comerciais, a` protec¸a˜ o contra a concorrˆencia desleal e todos os outros direitos inerentes a` atividade intelectual nos dom´ınios industrial, cient´ıfico, liter´ario e art´ıstico.” 1 Organizac ¸ a˜ o 2 World

das Nac¸o˜ es Unidas Intellectual Property Organization

17

2.2 Direitos Autorais e Propriedade Industrial

Desse modo, entende-se como propriedade intelectual: “(...) o direito que qualquer cidad˜ao, empresa ou instituic¸a˜ o tem sobre tudo o que resultar de sua inteligˆencia ou criatividade. Esse direito e´ protegido mediante variados instrumentos jur´ıdicos, que servem para dar seguranc¸a aos seus titulares (ou propriet´arios) contra o uso n˜ao-autorizado de sua criac¸a˜ o, talento ou inteligˆencia, por terceiros.” [9]

Em outras palavras, e´ um direito de propriedade privada sobre os produtos produzidos pela mente humana [7]. N˜ao existe ainda um “Direito de Propriedade Intelectual”, como ramo autˆonomo do Direito. De fato, sequer existe um sistema jur´ıdico unificado sobre a mat´eria (houve uma tentativa: o C´odigo de Propriedade Intelectual francˆes, de 1992, que ainda n˜ao conseguiu cumprir devidamente o papel pretendido), de modo que, ainda hoje, a quest˜ao “persiste sendo apenas um campo de pr´atica profissional e o objeto de instituic¸o˜ es administrativas nacionais ou supranacionais” [8].

2.2

Direitos Autorais e Propriedade Industrial

Dentro da propriedade intelectual, h´a duas categorias principais: os direitos autorais e a propriedade industrial. A Propriedade Industrial, regulada pela Convenc¸a˜ o de Paris, e´ um conjunto de direitos pertinentes a patentes de invenc¸a˜ o e modelos de utilidade, registro de desenho industrial e de marca, e de repress˜ao a` s falsas indicac¸o˜ es geogr´aficas

3

e concorrˆencia desleal, segundo elencado no

C´odigo de Propriedade Industrial brasileiro [11]. J´a os direitos autorais s˜ao os direitos do autor e os que lhe s˜ao conexos, abrangendo a regulamentac¸a˜ o da publicac¸a˜ o, transmiss˜ao, retransmiss˜ao, distribuic¸a˜ o, comunicac¸a˜ o ao p´ublico, contratac¸a˜ o e reproduc¸a˜ o de obras. O autor tem direitos de natureza moral e patrimonial. Os primeiros correspondem ao direito de ter seu nome registrado na obra, a` integridade desta, bem como o poder de modific´a-la e autorizar sua circulac¸a˜ o. J´a os direitos patrimoniais se referem a` utilizac¸a˜ o econˆomica da obra. Os sistemas de protec¸a˜ o aos direitos autorais e a propriedade industrial se diferenciam em trˆes pontos principais. Primeiramente, o direito industrial depende de um ato administrativo que lhe dˆe o direito de explorac¸a˜ o do bem imaterial, ou seja, o registro junto ao INPI – Instituto Nacional de Propriedade Intelectual, assim, se n˜ao for concedido, o autor n˜ao a possui, j´a 3 “Identificac ¸ a˜ o

de um produto ou servic¸o como origin´ario de um local, regi˜ao ou pa´ıs, quando determinada reputac¸a˜ o, caracter´ıstica e/ou qualidade possam ser vinculadas essencialmente a esta sua origem particular.” [10]

18

2.2 Direitos Autorais e Propriedade Industrial

que esse ato tem natureza constitutiva, e n˜ao declarat´oria; enquanto que o direito autoral n˜ao requer nenhum tipo de registro formal – a sua simples criac¸a˜ o da obra j´a enseja o direito de exclusividade do criador [9]. Em segundo lugar a diferenc¸a e´ no tocante a` extens˜ao da tutela. A explorac¸a˜ o exclusiva do invento vigora por no m´aximo 20 anos, enquanto que no caso de obra tutelada pelo direito autoral essa protec¸a˜ o e´ por 70 anos a partir da publicac¸a˜ o da obra. Ap´os esse per´ıodo, a obra ou invento entra em dom´ınio p´ublico. Diferente de outros ordenamentos jur´ıdicos, como nos Estados Unidos, onde e´ utilizada a propriedade industrial, o Brasil adota o direito autoral para proteger a propriedade intelectual referente ao software. Por´em, sua protec¸a˜ o e´ tutelada por 50 anos, diferentemente dos 70 anos atribu´ıdos normalmente a outras obras regidas pelo direito autoral. Observa-se na figura 2.1 a disposic¸a˜ o da Propriedade Intelectual no pa´ıs:

Propriedade Industrial

Propriedade Intelectual

Direito Autoral

Patentes Internacionais

Softwares

Patentes Nacionais

Bancos de Dados

Desenho Industrial

Documentos Técnicos

Marcas

Plantas

Nomes de Domínio

Outras Obras Protegidas pelo Direito

Figura 2.1: Divis˜ao da Propriedade Intelectual no Brasil H´a, ainda, uma terceira diferenc¸a entre o sistema de propriedade industrial e o dos direitos autorais, que diz respeito a` extens˜ao da protec¸a˜ o dada aos mesmos. Para os bens industriais, o

19

2.3 O Software e a Propriedade Intelectual no Brasil

Tabela 2.1: Diferenc¸as entre Direito Autoral e Propriedade Industrial Direito Autoral

Propriedade Industrial

In´ıcio da Protec¸a˜ o

Externalizac¸a˜ o da ideia

Registro no INPI

Durac¸a˜ o

70 anos (50 para softwares)

20 anos

Extens˜ao da Protec¸a˜ o

Forma

Ideia

que se protege e´ a ideia. Um inventor n˜ao poder´a criar uma patente sobre um objeto que seja apenas uma descric¸a˜ o diferente de outro j´a antes patenteado, j´a que a ideia que originou ambos foi a mesma. Por outro lado, o que se protege, no aˆ mbito dos direitos autorais, e´ a forma de exteriorizac¸a˜ o da obra. Por exemplo, uma ideia que j´a tenha sido abordada em certo livro pode ser perfeitamente parte da ideia de um novo livro, desde que o segundo autor n˜ao copie o texto e detalhes utilizados na primeira obra. N˜ao haver´a pl´agio, embora a ideia do outro livro n˜ao seja exatamente original [12]. O mesmo tipo de exemplo pode ser aplicado ao caso dos programas de computador: sabe-se que existem v´arios softwares distintos que servem, basicamente, a` mesma utilidade, e esse fato n˜ao torna nenhum deles “ilegal”.

2.3

O Software e a Propriedade Intelectual no Brasil

O art. 2o da lei 9.609 (Lei do Software) [13] estatui que o regime de protec¸a˜ o conferido aos programas de computador e´ o mesmo das obras liter´arias, que s˜ao protegidas pelos direitos autorais. Assim, o legislador decidiu incluir o software no rol das chamadas obras de criac¸a˜ o, no que houve uma especial influˆencia do Direito Internacional. Mas h´a de se indicar algumas diferenc¸as cruciais entre a relac¸a˜ o do usu´ario com a obra de arte e com o software. A primeira tem um fim em si mesmo, e sua reprovac¸a˜ o por parte do p´ublico n˜ao d´a ensejo a quase nenhum tipo de conseq¨ueˆ ncia jur´ıdica mais grave; o software, por sua vez, aproxima-se mais de um produto industrial, por possuir outro fim que n˜ao simplesmente a apreciac¸a˜ o, de modo que sua relac¸a˜ o com o usu´ario tem tamb´em um car´ater consumeirista. O titular de direitos autorais, portanto, n˜ao e´ isento de obrigac¸o˜ es para com o consumidor, em especial no caso dos programas de computador – para as demais obras de criac¸a˜ o, tais obrigac¸o˜ es se mostram um tanto vagas, praticamente insignificantes. Tendo em vista o acima disposto, e´ evidente que h´a posic¸o˜ es contr´arias a` classificac¸a˜ o do software como obra de criac¸a˜ o. De fato, no aˆ mbito de discuss˜ao da primeira Lei do Software

2.3 O Software e a Propriedade Intelectual no Brasil

20

brasileira, a Lei 7.232, de 29 de outubro de 1984 [14], havia maior tendˆencia a que se fosse adotado um regime espec´ıfico para protec¸a˜ o dos programas de computador, que n˜ao fosse nem o da propriedade industrial, nem o dos direitos autorais. Por´em, acabou-se decidindo pelo alinhamento pol´ıtico a` tendˆencia internacionalista de adoc¸a˜ o do direito autoral – no que e´ interessante assinalar a influˆencia do disposto no Trade Act de 1974 [15], no qual estavam previstas sanc¸o˜ es comerciais aos pa´ıses que n˜ao adotassem o regime supracitado em suas legislac¸o˜ es de software [8]. N˜ao se passou muito tempo, desde a promulgac¸a˜ o de nossa primeira Lei do Software, para que viessem as sugest˜oes em favor a` sua alterac¸a˜ o. Em 1998, foi promulgada, com efeito, a Lei 9.609 [13], que a substituiu, instituindo modificac¸o˜ es, principalmente, na esfera dos direitos de comercializac¸a˜ o do software (posto que extinguiu o processo de outorga dos mesmos), e assegurando tamb´em alguns direitos do consumidor. Manteve-se, contudo, o regime de protec¸a˜ o pelo Direito Autoral – tanto que a nova Lei do Software e a atual Lei do Direito Autoral, 9.610/98 [16], foram consecutivamente promulgadas. Visto isto, reitera-se que, com relac¸a˜ o ao software, n˜ao se aplica no Brasil a propriedade industrial, mas sim as Leis n.◦ 9.609/98 (Lei do Software) [13] e n.◦ 9.610/98 (Lei dos Direitos Autorais) [16], juntamente com o Decreto n.◦ 2.556/98 (disp˜oe sobre protec¸a˜ o da propriedade intelectual de programa de computador) [17]. O princ´ıpio da liberdade de express˜ao garante que o criador n˜ao tenha que registrar sua criac¸a˜ o (programas de computador, obras liter´arias, etc). Entretanto, nada impede que, se assim desejado, o produto seja registrado, no que e´ necess´ario seguir certas formalidades, estabelecidas no art. 3o , § 1o , da Lei 9.609 [13]: O pedido de registro estabelecido neste artigo dever´a conter, pelo menos, as seguintes informac¸o˜ es: I – os dados referentes ao autor do programa de computador e ao titular, se distinto do autor, sejam pessoas f´ısicas ou jur´ıdicas; II – a identificac¸a˜ o e descric¸a˜ o funcional do programa de computador; e III – os trechos do programa e outros dados que se considerar suficientes para identific´a-lo e caracterizar sua originalidade, ressalvando-se os direitos de terceiros e a responsabilidade do Governo.

Reforc¸a-se, desse modo, que o titular de direitos autorais n˜ao e´ isento de obrigac¸o˜ es, sendo estas, no tocante aos programas de computador, referentes, principalmente, a` relac¸a˜ o com o consumidor, que tem direito, no m´ınimo, a que o produto seja claramente identificado. E´ o interesse p´ublico que dita, primariamente, as limitac¸o˜ es aos direitos autorais sobre o software. E´ a importˆancia do produto na sociedade que determinar´a maiores ou menores prerrogativas de

2.3 O Software e a Propriedade Intelectual no Brasil

21

direitos autorais. O Estado tem a obrigac¸a˜ o de proteger a parte mais fraca da relac¸a˜ o, que nesse caso e´ o consumidor, j´a que, do outro lado, muitas vezes est˜ao grandes corporac¸o˜ es econˆomicas. Proteger o lado mais fr´agil e´ , ali´as, o pr´oprio objetivo do C´odigo de Defesa do Consumidor (CDC) [18]. Sendo assim, n˜ao obstante se inscreva entre as obras protegidas pelo regime de Direitos Autorais, o programa de computador tem tamb´em car´ater industrial, devido a` s finalidades espec´ıficas a` s quais se destina. No artigo 9o da lei 9.609 [13], temos uma pequena lista sobre ac¸o˜ es que podem ser executadas sobre o programa de computador sem que seus respectivos direitos autorais sejam violados: em primeiro lugar, permite-se, por quest˜ao de seguranc¸a, a produc¸a˜ o de c´opias-arquivo, que s˜ao reproduc¸o˜ es, em um u´ nico exemplar, da obra original legitimamente adquirida, para fins de salvaguarda ou armazenamento eletrˆonico. Em segundo lugar, admite-se a presenc¸a de citac¸o˜ es de outros programas de computador, desde que para fins did´aticos e sem prop´ositos comerciais, e apenas se n˜ao constitu´ırem a pr´opria ideia central do programa em quest˜ao. A mera semelhanc¸a entre programas de computador tamb´em n˜ao e´ pun´ıvel, at´e porque e´ comum que os autores retirem conhecimento de uma mesma fonte, tornando frequente, quase inevit´avel, a ocorrˆencia de similaridades. Por fim, tamb´em e´ permitida a integrac¸a˜ o de um programa a um sistema aplicativo ou operacional, para atendimento de necessidades exclusivas de quem realiza a operac¸a˜ o. Em outras palavras, se o resultado da integrac¸a˜ o n˜ao for distribu´ıdo, n˜ao constituir´a crime, mesmo que realizado sem autorizac¸a˜ o. Algumas outras garantias s˜ao feitas ao consumidor. O prazo de validade do produto dever´a estar claro e leg´ıvel, quando n˜ao na licenc¸a, na nota fiscal do produto, ou mesmo em sua embalagem, suporte f´ısico, o local em que se insere, enfim, quaisquer outros meios pelos quais possa ele ser identificado. A assistˆencia t´ecnica a que esse prazo de validade d´a ensejo, por sua vez, deve ser acess´ıvel e efetiva, pois o fornecedor do programa de computador n˜ao pode se isentar da responsabilidade de manter sua funcionalidade. O consumidor tem direito, inclusive, a reclamar por eventuais v´ıcios no produto adquirido. E´ comum, nesse caso, que tais v´ıcios sejam ocultos, s´o percebidos ap´os certo tempo de uso. Para ressarcir o consumidor, o CDC prevˆe, inclusive, o mecanismo da desconsiderac¸a˜ o da personalidade jur´ıdica, que impede o fornecedor (atrav´es de sanc¸o˜ es aplicadas diretamente a sua pessoa) de se ocultar por tr´as da personalidade da instituic¸a˜ o que representa para cometer abusos de direito [18].

2.4 Software Livre e Software Propriet´ario

2.4

22

Software Livre e Software Propriet´ario

A Convenc¸a˜ o de Berna, adotada pelo pa´ıs atrav´es do Decreto n.◦ 75.699/75 [19] e a Lei n.◦ 9.610/98 [16], em seu artigo 28, garante ao autor os direitos de uso, fruic¸a˜ o e disposic¸a˜ o da sua obra. Observam-se no mesmo sentido de acordo com Basso[4]: “O titular de um direito de patente ou marca e o autor ou escritor tˆem o direito de usar a invenc¸a˜ o patenteada, a marca depositada, o escrito, o livro, e o Direito lhes assegura os meios de determinar seu valor econˆomico. O titular pode ceder o uso da patente ou da marca em contrato de licenc¸a, assim como os autores em contrato de licenciamento ou concess˜ao de direitos autorais ou, mesmo, vender, atrav´es de contrato de cess˜ao, ou por outros meios admitidos em direito. Pode o titular abandonar seu direito de utilizar, fruir e dispor dos seus direitos, pura e simplesmente.”

Assim, esses criadores podem dispor de suas obras como bem entenderem, dentro dos limites do direito, e definir a forma com que terceiros podem usufruir delas. Desse modo, estabeleceu-se dentro da a´ rea da inform´atica, uma diferenciac¸a˜ o entre os softwares: os chamados softwares propriet´arios e os softwares livres. O software propriet´ario caracteriza-se por restringir o uso, modificac¸a˜ o e distribuic¸a˜ o do software. Normalmente, seus usu´arios n˜ao tˆem acesso ao c´odigo-fonte [20]. O exemplo mais R conhecido de software propriet´ario e´ o Microsoft Windows .

J´a o software livre e´ aquele cuja licenc¸a permite seu uso, modificac¸a˜ o e distribuic¸a˜ o, inclusive com fins comerciais. Para isto, e´ necess´ario que seu criador tamb´em disponibilize o c´odigo-fonte. De modo mais geral, e´ livre todo programa cuja licenc¸a permita o usufruto das seguintes quatro liberdades [21]: Liberdade 0 Executar o programa para qualquer objetivo; Liberdade 1 Estudar o programa e adapt´a-lo de acordo com as suas necessidades; Liberdade 2 Redistribuir c´opias e assim ajudar toda a comunidade; Liberdade 3 Aperfeic¸oar o programa e compartilhar as melhorias com todos os outros usu´arios.

2.5

Licenc¸as de Software

A cess˜ao de direitos autorais a terceiros e´ feita atrav´es de um documento, a licenc¸a do software, onde ele define sob que termos seu software pode ser utilizado [22]. Nesse sentido,

2.6 Licenc¸as de Software Livre

23

estabelece a Lei n. ◦ 9.609 [13]: Art. 9o O uso de programa de computador no Pa´ıs ser´a objeto de contrato de licenc¸a. Par´agrafo u´ nico. Na hip´otese de eventual inexistˆencia do contrato referido no caput deste artigo, o documento fiscal relativo a` aquisic¸a˜ o ou licenciamento de c´opia servir´a para comprovac¸a˜ o da regularidade do seu uso.

Desta forma, podemos perceber que quando compramos um software n˜ao estamos pagando pelo programa em si, mas pela sua licenc¸a. Convencionou-se que a licenc¸a de software e´ um contrato de ades˜ao, embora esse conceito tenha se enfraquecido com a admiss˜ao do documento fiscal como meio probat´orio. O contrato de ades˜ao e´ um instituto que, na verdade, est´a mais pr´oximo do regulamento que do contrato no sentido jur´ıdico formal da palavra, porque, nele, h´a uma evidente desigualdade entre as forc¸as: a parte mais fraca (o consumidor) adere a cl´ausulas estabelecidas pela outra parte, sem sequer ter conhecimento pr´evio sobre as mesmas, tendo apenas uma noc¸a˜ o vaga do produto a ser adquirido. Para impedir que sejam estabelecidas condic¸o˜ es excessivamente onerosas, uma verdadeira “servid˜ao contratual” do usu´ario, o Estado interv´em na relac¸a˜ o, instituindo parˆametros m´ınimos razo´aveis e socialmente aceitos a serem absorvidos pelas disposic¸o˜ es da licenc¸a [13].

2.6

Licenc¸as de Software Livre

S˜ao todas licenc¸as que permitem o exerc´ıcio das quatro liberdades 4 . Entretanto, essa cess˜ao de direitos n˜ao precisa ser incondicional. Podem haver restric¸o˜ es ao usufruto de alguma liberdade (normalmente a de distribuic¸a˜ o) [20]. Com relac¸a˜ o a estas condic¸o˜ es, as licenc¸as s˜ao classificadas como permissivas e heredit´arias. Estas sendo subdivididas em copyleft, lesser copyleft e share alike.

2.6.1

Permissivas

Elas n˜ao restringem o usufruto de nenhuma liberdade. Permitem inclusive que sejam criados trabalhos derivados ou combinac¸o˜ es cujas licenc¸as sejam mais restritivas que a do software original, podendo inclusive tornarem-se softwares propriet´arios. 4 Vide

sec¸a˜ o 2.4

24

2.6 Licenc¸as de Software Livre

Licenças Hereditárias

Licenças de Software Livre

Copyleft Permissivas

Share Alike Lesser Copyleft

Figura 2.2: Tipos de Licenc¸as de Software Livre 2.6.1.1

BSD

Criada pela Universidade da Calif´ornia em Berkeley, e´ uma licenc¸a simples que serviu de base para criac¸a˜ o de diversas outras. Por isto, pode gerar confus˜ao por qual das licenc¸as vocˆe est´a se referindo quando fala “a licenc¸a BSD”. Neste trabalho, quando nos referirmos a ela, estaremos falando da licenc¸a BSD de trˆes cl´ausulas [23]. 2.6.1.2

X11

Criada pelo Instituto de Tecnologia de Massachussets (MIT), e´ muito semelhante a` BSD de trˆes cl´ausulas. Entretanto, n˜ao sofre do problema de ter diversas vers˜oes. Por isto, a Free Software Foundation recomenda seu uso ao inv´es da BSD [23].

2.6.2

Copyleft

Criado pelo fundador da Free Software Foundation, Richard Stallman, e´ um dos conceitos mais importantes do software livre. Segundo Campos[21]: Copyleft e´ uma extens˜ao das 4 liberdades b´asicas, e ocorre na forma de uma obrigac¸a˜ o. Segundo o site da Free Software Foundation, “O copyleft diz que qualquer um que distribui o software, com ou sem modificac¸o˜ es, tem que passar adiante a liberdade de copiar e modificar novamente o programa. O copyleft garante que todos os usu´arios tem liberdade.” - ou seja: se vocˆe recebeu

2.6 Licenc¸as de Software Livre

25

um software com uma licenc¸a livre que inclua cl´ausulas de copyleft, e se optar por redistribu´ı-lo (modificado ou n˜ao), ter´a que mantˆe-lo com a mesma licenc¸a com que o recebeu.

E´ uma forma de garantir com que n˜ao s´o o software que vocˆe desenvolva seja livre, mas que tamb´em todas suas vers˜oes modificadas ou extendidas o sejam [24]. 2.6.2.1

GNU General Public License (GPL)

Criada pela Free Software Foundation, e´ a licenc¸a mais usada em softwares livres. Somadas as vers˜oes 2 e 3, est´a presente em 52,85% dos projetos [25]. Foi a escolhida pelo Linus Torvalds 5 para o Linux. Suas vers˜oes s˜ao incompat´ıveis entre si. Entretanto, e´ comum que os autores licenciem seus softwares sob a GPL “ou qualquer vers˜ao superior”. Desta forma, elas se tornam compat´ıveis. Esse termo adicional e´ usualmente representado adicionando “+” ao nome da licenc¸a. Assim, GPLv2 se torna GPLv2+, GPLv3 se torna GPLv3+, etc. [23].

2.6.3

Lesser Copyleft

E´ uma licenc¸a copyleft com uma excec¸a˜ o que permita alguma forma de combinac¸a˜ o com outros trabalhos, sem que o produto resultante herde a mesma licenc¸a. Normalmente s˜ao usadas em bibliotecas, para que os programas que a utilizem possam ser licenciados como seus autores desejarem. 2.6.3.1

GNU Lesser General Public License (LGPL)

Muito semelhante a` GPL 6 , inclusive podendo ser relicenciada sob ela. A diferenc¸a mais marcante e´ que a LGPL permite que c´odigo que esteja sob ela seja linkado dinˆamicamente com outros projetos, sem obrig´a-los a se tornar LGPL [26]. 2.6.3.2

Common Development and Distribution License (CDDL)

Criada pela Sun Microsystems, foi baseada na Mozilla Public License (MPL). E´ usada no OpenSolaris, NetBeans entre outros. Suas cl´ausulas lesser copyleft se aplicam somente ao 5 Criador 6 Vide

do Linux sec¸a˜ o 2.6.2.1

2.7 Linguagens de Express˜ao de Direitos

26

c´odigo contido em um mesmo arquivo [27]. Tudo dentro do mesmo fonte dever´a estar sob ela, mas n˜ao h´a restric¸o˜ es para o que estiver em arquivos separados [27].

2.6.4

Share Alike

Outro conceito importante e´ o de Share Alike. Esse tipo de licenc¸a obriga que o usu´ario ao modificar o c´odigo ou simplesmente distribuir o original deve distribu´ı-lo sob a mesma licenc¸a do trabalho original. E´ muito semelhante ao conceito de Copyleft. A diferenc¸a e´ que este s´o e´ usado para denotar licenc¸as de software livre, enquanto Share Alike e´ usado pra qualquer licenc¸a que possua essas caracter´ısticas [28] [29]. 2.6.4.1

Attribution-ShareAlike (BY-SA)

Criada pela Creative Commons, e´ uma das licenc¸as Share Alike mais usadas, sendo adotada pela Wikipedia, Google Knol, Citizendium, a maioria das mais de 100.000 [30] wikis hospedadas na Wikia [31] entre outros. Ela permite uso, distribuic¸a˜ o, modificac¸a˜ o e venda, contanto que o autor seja citado e que quaisquer trabalhos derivados sejam licenciados sob ela [32].

2.7

Linguagens de Express˜ao de Direitos

As Linguagens de Express˜ao de Direitos (REL 7 ) fazem parte das tecnologias de Gest˜ao de Direitos Digitais (DRM 8 ). Relativamente novas, com as primeiras aparecendo no final da d´ecada de 90, podem ter um ou mais dos seguintes objetivos [33]: • Express˜ao de direitos autorais; • Express˜ao de acordos contratuais ou de licenc¸as; • Controle sobre o acesso e/ou uso. Dependendo de seu foco, as RELs podem ser mais ou menos precisas. Por exemplo, linguagens que foram criadas para serem processadas por m´aquinas precisam ser muito precisas e 7 Rights 8 Digital

Expression Languages Rights Management

2.7 Linguagens de Express˜ao de Direitos

27

com ela pode-se quase garantir o cumprimento dos termos expressos. Entretanto, este tipo de REL n˜ao poder´a analisar conceitos sociais ou legais mais sutis, como o “fair use” 9 [33]. Existem diversas linguagens de express˜ao de direitos. Dentre elas, podemos citar [34]: Creative Commons Rights Expression Language (ccREL) Criada pela Creative Commons para expressar suas licenc¸as, foi adotada pelo Projeto GNU; Open Digital Rights Language (ODRL) Usada pela Open Mobile Alliance; eXtensible Rights Markup Language (XrML) Criada pela Xerox na d´ecada de 90, deu origem a MPEG-21/5; MPEG-21/5 E´ a linguagem de express˜ao de direitos padr˜ao do MPEG.

2.7.1

Creative Commons Rights Expression Language – ccREL

E´ o “padr˜ao recomendado pela Creative Commons (CC) para a descric¸a˜ o leg´ıvel por m´aquina de termos de copyright e informac¸o˜ es relacionadas.” [35] Ele usa a RDF10 da W3C11 , o que o torna facilmente extens´ıvel. Para descrever termos de licenc¸as de software, a CC definiu 10 atributos12 , sendo 3 permiss˜oes, 6 requisitos e 1 proibic¸a˜ o, como mostrados na tabela 2.2. Com esta linguagem e´ poss´ıvel descrever licenc¸as de software de uma forma process´avel por um computador. A tabela 2.3 mostra diversas licenc¸as da Creative Commons e da Free Software Foundation com suas respectivas caracter´ısticas descritas de acordo com a ccREL. Entretanto, existem atributos que n˜ao est˜ao mapeados na linguagem. Por exemplo, a licenc¸a GPL em suas vers˜oes 2 e 3 possui o mesmo conjunto de atributos. Apesar de serem diferentes, elas possuem a mesma descric¸a˜ o na ccREL. Tamb´em, no caso de licenc¸as Lesser Copyleft, n˜ao h´a diferenciac¸a˜ o com relac¸a˜ o a forma que elas permitem que combinac¸o˜ es com o trabalho sejam licenciados sob outros termos, que n˜ao o delas. Mas, pela escolha do RDF como forma de representac¸a˜ o da linguagem, e´ trivial adicionar atributos que contemplem esses casos. 9 No Brasil, conhecido como “limitac ¸ o˜ es aos direitos autorais” que permite, dentre outros, “a reproduc¸a˜ o, em um

s´o exemplar de pequenos trechos, para uso privado do copista, desde que feita por este, sem intuito de lucro” [16]. O termo “pequenos trechos” e´ subjetivo, podendo ter diversas interpretac¸o˜ es dependendo do local, e´ poca e leitor. Assim sendo, n˜ao e´ poss´ıvel formaliz´a-lo em uma REL. 10 Resource Description Framework – http://www.w3.org/RDF/ 11 World Wide Web Consortium – http://www.w3.org/ 12 Originalmente eram 12 atributos, mas a permiss˜ ao Sharing e a proibic¸a˜ o High Income Nation Use s˜ao consideradas obsoletas e n˜ao s˜ao mais citadas pela pr´opria Creative Commons [35]. Desta forma, n˜ao os consideramos neste trabalho.

2.8 Compatibilidade entre Licenc¸as de Software

28

Tabela 2.2: Atributos definidos pelo ccREL Permiss˜oes Reproduction Distribution DerivativeWorks

Criar m´ultiplas c´opias. Distribuic¸a˜ o, exibic¸a˜ o e performance p´ublica. Distribuic¸a˜ o de trabalhos derivados. Requisitos

Notice

Notas de licenc¸a e copyright devem ser mantidas intactas.

Attribution

Deve ser dado cr´edito ao detentor do copyright e/ou autor.

Share Alike

Trabalhos derivados devem ser licenciados sob termos iguais ou compat´ıveis com os do trabalho original.

Source Code

C´odigo fonte (a forma prefer´ıvel de serem feitas modificac¸o˜ es) deve ser fornecido quando exercendo alguns dos direitos garantidos pela licenc¸a.

Copyleft

Trabalhos derivados e combinados devem ser licenciados sob os termos especificados, similares aos do trabalho original.

Lesser Copyleft

Trabalhos derivados devem ser licenciados sob os termos especificados, com pelo menos as mesmas condic¸o˜ es do trabalho original; combinac¸o˜ es com o trabalho podem ser licenciadas sob termos diferentes. Proibic¸o˜ es

Commercial Use

2.8

Exercer os direitos com fins comerciais.

Compatibilidade entre Licenc¸as de Software

Poucos softwares s˜ao completamente desenvolvidos por uma u´ nica empresa hoje em dia. A maioria utiliza partes criadas por terceiros, sejam bibliotecas, componentes ou o pr´oprio sistema operacional. Desta forma, o produto final e´ composto por um conjunto de pec¸as feitas por pessoas diferentes [20]. Essas pec¸as s˜ao protegidas pelo direito autoral. Para us´a-las e´ necess´aria autorizac¸a˜ o, na forma de uma licenc¸a, dada pelos seus autores. Os termos da licenc¸a de cada parte que forma o sistema devem ser analisados, para garantir que os direitos que est˜ao sendo repassados aos usu´arios do software como um todo est˜ao de acordo com os que se possui de cada parte. Que os direitos “de sa´ıda” s˜ao no m´aximo iguais (mas n˜ao maiores) que os “de entrada”. Al´em disto, as licenc¸as das partes devem ser compat´ıveis entre si [20]. Segundo Meeker[20]:

Permiss˜oes

Requisitos

Proibic¸o˜ es

X

X

Distribution

DerivativeWorks

X

X

X

X

X

X

BY-SA

X

X

X

X

X

X

BY-NC

X

X

X

X

BY-ND

Commercial Use

Lesser Copyleft X

X

X

X

X

X

BY-NC-ND

X

X

X

X

X

X

BY-NC-SA

X

X

X

X

GPL

X

X

X

X

X

X

BY

Copyleft

X

X

X

X

X11

X

X

X

X

X

BSD

Source Code

Share Alike

Attribution

Notice

X

Reproduction

PD

Tabela 2.3: Licenc¸as descritas com o ccREL

X

X

X

X

X

X

LGPL

2.8 Compatibilidade entre Licenc¸as de Software 29

2.8 Compatibilidade entre Licenc¸as de Software

30

“Colocar diferentes tipos de software juntos e´ como fazer um jantar para meus parentes. Talvez, se eu me esforc¸ar bastante, eu consiga servir comida que todo mundo comer´a: meu tio de meia-idade em sua dieta de baixo carboidrato quer carne e peixe; minha irm˜a vegan s´o quer vegetais produzidos localmente; e meu sobrinho adolescente comer´a qualquer coisa contanto que seja do McDonald’s. Mas e se os convidados pro jantar n˜ao s´o tenham suas pr´oprias preferˆencias, mas um veemente, polˆemico disgosto pela comida que os outros comem? Seria dif´ıcil colocar todos na mesma mesa. E´ assim que o mundo do software pode ser atualmente.” 13 (Traduc¸a˜ o livre do autor)

Existem dois tipos de compatibilidade entre licenc¸as: a de relicenciamento e a de combinac¸a˜ o [20].

2.8.1

Relicenciamento

Quando o software possui diversas partes, cada qual com autor distinto, e se deseja un´ı-los em um sistema u´ nico, gerido por uma u´ nica licenc¸a, h´a uma situac¸a˜ o de relicenciamento [20]. Perceba que cada parte, separada, continua sob a licenc¸a escolhida por seu autor, s´o ele pode modificar os termos que sua criac¸a˜ o e´ licenciada. O que e´ feito e´ simplesmente que o conjunto estar´a licenciado sob termos diferentes, que n˜ao substituem os termos de cada parte. Na figura 2.3, h´a um exemplo onde uma desenvolvedora fict´ıcia, chamada Luana, criou um projeto com duas partes: um de sua autoria (logo, ela possui todos os direitos), e outro de terceiros, para o qual ela possui uma licenca sublicenci´avel14 com permiss˜oes para distribuir, copiar e criar trabalhos derivados. Ela deseja unir essas duas partes no projeto e repassar uma licenc¸a com permiss˜oes para distribuir, copiar e preparar trabalhos derivados para seus clientes. Isto e´ poss´ıvel, pois as permiss˜oes que ela possui s˜ao maiores do que as que quer repassar. J´a na figura 2.4 h´a outro projeto da Luana, semelhante ao anterior. Nesse caso o sistema tamb´em e´ composto por duas partes, uma de sua autoria e outra de terceiros. Mas, diferente do caso da figura 2.3, para a parte desenvolvida por outrem ela s´o possui uma licenc¸a sublicenci´avel com permiss˜oes para distribuir e copiar. E, novamente, ela quer repassar aos seus clientes uma licenc¸a com permiss˜oes para distribuir, copiar e criar trabalhos derivados. Ela est´a tentando repassar uma permiss˜ao (de criar trabalhos derivados) que n˜ao possui. Est´a tentando repassar mais permiss˜oes do que tem. Se fizer isso, n˜ao s´o estar´a violando o 13 “Putting

different kinds of software together is like holding a dinner party for my relatives. Maybe, if I go to a lot of work, I can serve food every- one will eat: My middle-age uncle on his low-carb diet wants meat and fish; my sister the vegan wants only locally grown vegetables; and my teenage nephew will eat anything as long as it comes from McDonald’s. But what if all the dinner guests have not only their own preferences, but a vehement, polemical disgust for the foods the others eat? It is hard to bring everyone to the same table. That is what the software world can be like today.” 14 Licenc ¸ a cujos direitos podem ser repassados para terceiros.

31

2.8 Compatibilidade entre Licenc¸as de Software

Código Da Luana s eito Dir

dos

Aut

Projeto

L ic en dis ca su trib blic tra uir, c enciá v bal hos opiar el pa ra der e c r i va dos iar

Entrada

o = T oria

Código De Terceiros

Lic

Saída

enc a cop para dis tra iar e tr bal hos prepa ibuir, ra der ivad r os

Clientes

Figura 2.3: Relicenciamento com sucesso

Código Da Luana

dos

s eito Dir

Projeto

L ic en dis ca su trib blic tra uir, c enciá v bal hos opiar el pa ra der e c r i va dos iar

Entrada

Aut

o = T oria

Código De Terceiros

Diferentes Lic

Clientes

Figura 2.4: Relicenciamento falho

Saída

enc a cop para dis tra iar e tr bal hos prepa ibuir, ra der ivad r os

32

2.8 Compatibilidade entre Licenc¸as de Software

Código Da Luana

ria

o Aut

s

= T

Projeto

LG PL = (le sse Here r c d opy itária lef t)

Entrada

eito

ir s D odo

Código De Terceiros

Diferentes

= P erm is

siva

Saída

BSD

Clientes

Figura 2.5: Relicenciamento falho por restric¸o˜ es nas licenc¸as direito autoral do criador daquela parte, mas tamb´em far´a com que seus clientes o violem, mesmo sem saber. Neste caso, o problema foi que as permiss˜oes “de entrada” foram menores que as “de sa´ıda”. H´a um caso um pouco diferente, onde o problema n˜ao e´ a falta de permiss˜oes, mas as condic¸o˜ es das licenc¸as. Vejamos a figura 2.5. Na figura 2.5 h´a outro projeto da Luana. Neste ela quer unir c´odigo de sua autoria com c´odigo licenciado sob a LGPL, e relicenciar o todo sob a BSD. Tanto a LGPL quanto a BSD s˜ao licenc¸as de software livre. Logo, ambas nos permitem o usufruto das quatro liberdades 15 : uso para qualquer fim, c´opia, distribuic¸a˜ o e criac¸a˜ o de trabalhos derivados. Entretanto, a LGPL e´ uma licenc¸a lesser copyleft16 . Ou seja, ela forc¸a que todos trabalhos derivados sejam licenciados sob ela pr´opria. Assim, a u´ nica forma de n˜ao violarmos os direitos do autor e´ relicenciando o projeto todo sob a LGPL17 ou n˜ao usando essa parte. 15 Vide

sec¸a˜ o 2.4. sec¸a˜ o 2.6.3. 17 Tamb´ em poder´ıamos relicenciar o projeto sob a GPL, pois a LGPL, no seu 3 ◦ par´agrafo permite explicitamente isto. 16 Vide

33

2.8 Compatibilidade entre Licenc¸as de Software

Código LGPL

Código Da Luana

Autoria

Link dinâmico OK

Projeto Link Dinâmico Clientes Figura 2.6: Combinac¸a˜ o com c´odigo LGPL

2.8.2

Combinac¸a˜ o

H´a uma soluc¸a˜ o para o caso da figura 2.5 que nos permite unir nosso c´odigo com o sob a LGPL, sem precisarmos relicenciar o projeto todo sob a LGPL: a combinac¸a˜ o. Na combinac¸a˜ o, o projeto n˜ao e´ visto como um sistema u´ nico, mas como um conjunto de partes, cada qual com sua licenc¸a independente. Pode-se pensar na combinac¸a˜ o como uma quest˜ao de compatibilidade horizontal, enquanto o relicenciamento e´ compatibilidade vertical [20]. Voltando a figura 2.5, a Luana poderia usar a parte LGPL e licenciar seu projeto sob a BSD se, quando o criasse, essa parte fosse usada como uma biblioteca linkada dinˆamicamente. A LGPL possui uma excess˜ao que permite essa forma de uni˜ao sem que o todo precise ser relicenciado sob ela [26]. O sistema ficaria como representado na figura 2.6. Licenc¸as heredit´arias s˜ao, quase sempre

18 ,

incompat´ıveis verticalmente entre si. Mas as

lesser copyleft tˆem excec¸o˜ es que podem torn´a-las compat´ıveis horizonalmente, dependendo da forma de combinac¸a˜ o [20]. Na figura 2.7 h´a um exemplo onde, em um mesmo projeto, existem partes licenciadas sob 18 Exceto

quando h´a um termo espec´ıfico no corpo da licenc¸a que a torna compat´ıvel com outra, como no caso da LGPL ser relicenci´avel para a GPL.

34

2.8 Compatibilidade entre Licenc¸as de Software

Código BSD

Código CDDL

Código LGPL Permissiva

Link dinâmico OK

Arquivo separado OK

Projeto Código Linkado Dinâmicamente Clientes Figura 2.7: Combinac¸a˜ o com sucesso entre licenc¸as BSD, LGPL e CDDL duas licenc¸as lesser copyleft distintas: a LGPL e a CDDL. H´a ainda uma parte sob a BSD mas, como toda licenc¸a permissiva, normalmente ela n˜ao gera problemas de compatibilidade. Se o c´odigo LGPL for linkado dinˆamicamente e o CDDL estiver em arquivos diferentes, os direitos de todos os autores estar˜ao sendo representados. As licenc¸as das partes LGPL e CDDL n˜ao podem ser modificadas. Mas pode-se relicenciar somente a parte BSD para outra que seja compat´ıvel horizontalmente com as outras. Ao final, este projeto ter´a trˆes partes com licenc¸as distintas: BSD (ou outra compat´ıvel), LGPL e CDDL. J´a na figura 2.8 h´a uma situac¸a˜ o sem soluc¸a˜ o. Nela h´a as licenc¸as BSD e CDDL, como na figura 2.7, mas ao inv´es da LGPL, temos a GPL. Aqui temos termos incompat´ıveis. A GPL exige que todo trabalho derivado dela seja relicenciado sob os mesmos termos, n˜ao importando a forma que a parte seja usada. A CDDL exige que todo arquivo que tenha c´odigo licenciado sob ela seja relicenciado sob a mesma. N˜ao h´a como cumprir os requisitos da GPL e da CDDL ao mesmo tempo, ent˜ao a u´ nica soluc¸a˜ o e´ deixar de usar uma das partes.

35

2.8 Compatibilidade entre Licenc¸as de Software

Código BSD

Código CDDL

Código GPL Permissiva

Todos trabalhos baseados no Programa

Todo código no mesmo arquivo

Projeto Problema no Cumprimento de Restricões

Clientes Figura 2.8: Combinac¸a˜ o falha entre licenc¸as BSD, GPL e CDDL

36

3

Modelo de verificac¸a˜ o de compatibilidade entre licenc¸as de software

A partir dos atributos definidos no ccREL, extraiu-se um conjunto de regras que conseguem detectar se duas licenc¸as de software s˜ao ou n˜ao compat´ıveis, tanto com relac¸a˜ o a relicenciamento quanto a combinac¸a˜ o.

3.1

Relicenciamento

Neste exemplo considera-se que quer-se relicenciar um software que est´a sob a licenc¸a A para a licenc¸a B, representado como A → B. 1. A permite criac¸a˜ o de trabalhos derivados; 2. Todas permiss˜oes de B devem estar em A; 3. Todos requisitos de A devem estar em B; 4. Todas proibic¸o˜ es de A devem estar em B; 5. Se A for Copyleft ou Lesser Copyleft, B deve ser igual a A; 6. Se A for Share Alike, B deve ser igual a A, podendo ser de uma vers˜ao diferente. Esse algoritmo est´a representado no fluxograma da figura 3.1.

3.1.1

BSD → GPL

Na tabela 2.3 pode-se ver os atributos dessas licenc¸as. Seguindo o algoritmo da sec¸a˜ o 3.1, tem-se:

37

3.1 Relicenciamento

Início A permite Trabalhos Derivados?

Todas permissões de B estão em A?

Não

Sim Todos requisitos de A estão em B?

Não

Sim Todas proibicões de A estão em B?

Não

Sim A não é Copyleft nem Lesser Copyleft?

Não

Sim A é relicenciável em B

Não

Sim

Sim

A não é Share Alike?

B é igual a A?

Não

B é igual a A, independente de versão?

Não

Sim A não é relicenciável em B

Fim Figura 3.1: Fluxograma de compatibilidade de relicenciamento

3.2 Combinac¸a˜ o

38

1. A BSD permite a criac¸a˜ o de trabalhos derivados; 2. Todas as permiss˜oes da GPL est˜ao na BSD; 3. Todos os requisitos da BSD est˜ao na GPL; 4. Todas as proibic¸o˜ es da BSD est˜ao na GPL; 5. A BSD n˜ao e´ Copyleft nem Lesser Copyleft; 6. A BSD n˜ao e´ Share Alike. Assim, a BSD e´ relicenci´avel para a GPL.

3.1.2

GPL → BSD

Aqui tem-se o caso inverso da sec¸a˜ o anterior. Novamente vendo os atributos na tabela ??. 1. A GPL permite a criac¸a˜ o de trabalhos derivados; 2. Todas as permiss˜oes da BSD est˜ao na GPL; 3. Todos os requisitos da GPL est˜ao na BSD; 4. Todas as proibic¸o˜ es da GPL est˜ao na BSD; 5. A GPL e´ Copyleft, mas e´ diferente da BSD; 6. A GPL n˜ao e´ Share Alike. O item 5 falhou. Desta forma, a GPL n˜ao e´ relicenci´avel para a BSD. Desses exemplos pode-se ver uma caracter´ıstica da compatibilidade de relicenciamento: A ser relicenci´avel para B n˜ao significa que B e´ relicenci´avel para A.

3.2

Combinac¸a˜ o

Para combinac¸a˜ o entre as licenc¸as A e B, tem-se o seguinte algoritmo, tamb´em representado no fluxograma na figura 3.2: 1. A e B permitem a criac¸a˜ o de trabalhos derivados;

39

3.2 Combinac¸a˜ o

2. Se A ou B for Copyleft ou Share Alike, ent˜ao A deve ser relicenci´avel em B ou B deve ser relicenci´avel em A; Para compatibilidade de combinac¸a˜ o, consider-se que licenc¸as Lesser Copyleft s˜ao compat´ıveis entre si, mas isto nem sempre e´ verdadeiro. Depende da forma com que as partes s˜ao combinadas, que tˆem que ser permitidas pelas licenc¸as. Pelo pr´oprio algoritmo pode-se ver que, ao contr´ario do relicenciamento, na combinac¸a˜ o se A e´ combin´avel com B, ent˜ao B e´ combin´avel com A.

Início A e B permitem Trabalhos Derivados?

A ou B não são Copyleft nem Share Alike?

Não

A é relicenciável em B? Sim

Sim

Não

B é relicenciável em A?

Não

Sim

A e B são combináveis

A e B não são combináveis

Fim Figura 3.2: Fluxograma de compatibilidade de combinac¸a˜ o

3.2.1

BSD e GPL

1. A BSD e GPL permitem a criac¸a˜ o de trabalhos derivados; 2. A GPL e´ Copyleft, mas a BSD e´ relicenci´avel sob a GPL1 . Desta forma, a BSD e a GPL s˜ao combin´aveis. 1 Como

vimos na sec¸a˜ o 3.1.1.

3.3 Compatibilidade entre mais de duas licenc¸as

3.2.2

40

BY e BY-ND

1. A BY permite a criac¸a˜ o de trabalhos derivados, mas a BY-ND n˜ao; 2. Nem a BY nem a BY-ND s˜ao Copyleft ou Share Alike. O algoritmo falha j´a no primeiro passo. A licenc¸a BY-ND n˜ao permite trabalhos derivados, e qualquer combinac¸a˜ o e´ considerada um trabalho derivado. Logo, ela n˜ao pode ser combinada com nenhuma outra.

3.3

Compatibilidade entre mais de duas licenc¸as

Todos exemplos anteriores consideram somente duas licenc¸as, mas a maioria dos casos e´ mais complexa, envolvendo at´e dezenas de licenc¸as distintas. Para isto, a compatibilidade e´ verificada de uma forma diferente dependendo se testamos com relac¸a˜ o ao relicenciamento ou a combinac¸a˜ o. No relicenciamento, deve-se, individualmente, testar se cada licenc¸a do projeto e´ relicenci´avel para a qual quer-se relicenciar. Por exemplo, em um sistema que possua partes sob a BSD, X11 e GPL, e quer-se relicenci´a-lo para a GPL, deve-se testar BSD → GPL, Apache → GPL e GPL → GPL. Se algum falhar, o o relicenciamento como um todo e´ imposs´ıvel. No caso de combinac¸a˜ o, testa-se cada licenc¸a com todas as outras. Usando o mesmo projeto do exemplo anterior, deve-se testar BSD + X11, BSD + GPL e X11 + GPL. Perceba que s´o e´ preciso testar os pares u´ nicos, independente da ordem. Mais uma vez, se qualquer um falhar, a combinac¸a˜ o como um todo e´ imposs´ıvel.

41

License Compatibility Checker (licc)

4

O licc e´ uma ferramenta para a verificac¸a˜ o de compatibilidade entre licenc¸as. A partir de um conjunto de licenc¸as descritos na ccREL, ela consegue definir a compatibilidade com relac¸a˜ o a combinac¸a˜ o ou relicenciamento. Ela foi feita para facilitar o trabalho de um advogado especializado, mas n˜ao substitu´ı-lo.

4.1 4.1.1

Cen´arios Cen´ario 1: Samara

Samara e´ a gerente t´ecnica do projeto MusiMed, sistema de medicina alternativa que cura pacientes atrav´es da m´usica e cromoterapia 1 . Este programa usa dois componentes desenvolvidos por terceiros: uma biblioteca para tocar arquivos de m´usica, e uma para exibir e modificar cores no monitor do computador. Elas est˜ao sob as licenc¸as X11 e BSD, respectivamente. E Samara quer licenciar o MusiMed sob a GPLv3. Para descobrir se isto e´ poss´ıvel, ela executa o licc testando se o conjunto de licenc¸as X11 e BSD s˜ao relicenci´aveis para a GPLv3. Rapidamente, ela recebe a resposta: sim, e´ poss´ıvel. A partir da´ı, ela pode se dedicar ao marketing de seu produto, tendo certeza que n˜ao estar´a violando os direitos de ningu´em.

4.1.2

Cen´ario 2: Dione

Dione e´ uma estudante de computac¸a˜ o. Nas horas vagas entre as aulas de C´alculo e F´ısica, ela fica no laborat´orio de inform´atica desenvolvendo o jogo MinerMan, onde o usu´ario incorpora um mineiro que deve resolver desafios para chegar ao tesouro. No seu jogo ela usou a biblioteca Gosu para os gr´aficos e a Open Dynamics Engine (ODE) 1 Pr´ atica

de utilizac¸a˜ o de cores na cura de doenc¸as.

4.2 Requisitos Funcionais

42

para as simulac¸o˜ es f´ısicas. A primeira e´ licenciada sob a MIT, e a segunda sob a BSD. Depois de quase um ano em desenvolvimento, ela finalmente est´a pr´oxima de lanc¸ar o MinerMan. Mas, antes disto, ela quer saber sobre qual licenc¸as pode licenci´a-lo. Para descobrir a resposta, ela usa o licc, passando as licenc¸as MIT e BSD e vendo as opc¸o˜ es de relicenciamento. Da lista mostrada, ela escolhe sua preferida: a GPL. Sabendo que n˜ao h´a mais nenhum impecilho, ela finalmente pode lanc¸ar seu jogo.

4.1.3

Cen´ario 3: Nath´alia

Nath´alia e´ uma webdesigner. Ela acabou de ser contratada para fazer a reformulac¸a˜ o da p´agina de um evento local de software livre. Pesquisando na internet, ela encontrou algumas fotos da cidade que gostaria de usar no site. Todas est˜ao licenciadas sob licenc¸as da Creative Commons, mas algumas est˜ao sob a BY, outras BY-SA e outras sob a BY-NC. Ela quer saber se pode edit´a-las e un´ı-las no design. Usando o licc, ela descobre que a BY-NC e´ incompat´ıvel com a BY-SA, al´em de n˜ao permitir uso comercial, ent˜ao ela j´a descarta essas fotos. J´a a BY e´ compat´ıvel, mas o design ter´a de ser licenciado sob a BY-SA. Conversando com seu contratante, ele concorda que o site esteja sob a BY-SA. Ela j´a pode comec¸ar a trabalhar.

4.2

Requisitos Funcionais

• Possuir um reposit´orio de licenc¸as conhecidas; • Ler licenc¸as a partir de arquivo, URL ou nome (quando a licenc¸a estiver no reposit´orio); • Verificar compatibilidade com relac¸a˜ o a combinac¸a˜ o de duas ou mais licenc¸as; • Verificar compatibilidade com relac¸a˜ o ao relicenciamento de uma ou mais licenc¸as em outra; • Dado uma ou mais licenc¸as, listar as possibilidades de relicenciamento com relac¸a˜ o as licenc¸as dispon´ıveis no reposit´orio; • Exibir atributos das licenc¸as; • Exibir atributos da licenc¸a resultante de combinac¸a˜ o ou relicenciamento.

4.3 Requisitos N˜ao-Funcionais

43

Figura 4.1: Diagrama de caso de uso

4.3

Requisitos N˜ao-Funcionais

• Possuir interface de linha de comando; • Interpretar licenc¸as descritas na ccREL usando o formato RDF/XML;

4.4

Arquitetura

A arquitetura do licc foi elaborada de forma a facilitar a adic¸a˜ o de novas RELs, cada qual com seu parser, atributos e algoritmos de compatibilidade entre licenc¸as. Ela e´ formada por cinco classes principais: License, Licenses, Parser, CompatibilityChecker e CLI. Destas, somente Licenses e CLI n˜ao s˜ao abstratas. As classes em laranja na figura 4.2 s˜ao exemplos da implementac¸a˜ o de duas RELs nessa arquitetura: a ccREL e a MPEG21/5. License e´ o ponto de entrada do software. Suas subclasses representam os atributos de licenc¸as de cada REL que o licc suporte (no exemplo, CCREL e MPEG21/5). Ainda possui

44

4.4 Arquitetura

Figura 4.2: Diagrama de classes m´etodos para o carregamento de licenc¸as e verificac¸a˜ o de compatibilidade, os quais ela delega para as classes que herdam de Parser e CompatibilityChecker, respectivamente. A classe Parser simplesmente delega o parsing para suas subclasses, dependendo do formato da licenc¸a que se quer carregar. A CompatibilityChecker tamb´em somente delega para suas subclasses, mas a verificac¸a˜ o de compatibilidade, dependendo do par de licenc¸a de “origem” e “alvo”.

4.5 Validac¸a˜ o

45

A classe Licenses possui um conjunto de objetos License. Ela e´ usada para testes de compatibilidade entre mais de duas licenc¸as. A CLI e´ a interface de linha de comando. Ela trata os parˆametros passados e apresenta o resultado ao usu´ario.

4.5

Validac¸a˜ o

A parte mais importante do desenvolvimento do licc foi sua validac¸a˜ o. E´ preciso garantir que a ferramenta gera resultados corretos, pois uma falha pode acarretar em preju´ızos financeiros. Uma empresa, usando o licc, poderia pensar que estava de acordo com as licenc¸as dos componentes de seus sistemas, quando na verdade n˜ao estava. Para tanto, foi criada uma su´ıte com os testes descritos na tabela 4.2 baseada em an´alises de compatibilidade feitas pela filial da Creative Commons de Taiwan [5] e pela Free Software Foundation [6] [23]. Ela foi implementada usando o RSpec 2 e o Cucumber 3 .

2 http://rspec.info 3 http://cukes.info

Licenc¸a Original

X

X

X

X

X

BY-NC

X

X

X

X

X

BY-NC-ND

X

X

X

X

X

X

BY-NC-SA

X

X

X

X

BY-ND

X

X

X

GPL

X

X

X

X

X

X

BY-SA

LGPL

X

X

X

X

BY

X

X

X

X

X11

GPL

BY-SA

BY-ND

BY-NC-SA

BY-NC-ND

BY-NC

BY

X

X11

X X

X

BSD

BSD

PD

PD

Licenc¸as que podem ser usadas em trabalhos derivados ou adaptac¸o˜ es

Tabela 4.1: Compatibilidade de relicenciamento entre as licenc¸as

X

X

X

X

LGPL

4.5 Validac¸a˜ o 46

Licenc¸a Original

X

X

X

X11

BY

BY-NC

X

X

X

BY-SA

GPL

LGPL

BY-ND

BY-NC-SA

X

X

BSD

BY-NC-ND

X

PD

PD

X

X

X

X

X

X

X

X

X

BSD

X

X

X

X

X

X

X

X

X

X11

X

X

X

X

X

X

X

X

BY

X

X

X

X

X

X

X

BY-NC

BY-NC-ND

X

X

X

X

X

X

BY-NC-SA

BY-ND

Licenc¸as que podem ser usadas em combinac¸o˜ es

Tabela 4.2: Compatibilidade de combinac¸a˜ o entre as licenc¸as

X

X

X

X

X

BY-SA

X

X

X

X

X

GPL

X

X

X

X

X

X

LGPL

4.5 Validac¸a˜ o 47

48

5

Estudo de Caso

5.1

GingaInstancing

O GingaInstancing faz parte do projeto GingaCDN, uma rede de desenvolvimento distribu´ıda de componentes e ferramentas de apoio para o padr˜ao de middleware brasileiro de TV Digital – o Ginga. A partir de um conjunto m´ınimo desses componentes pode-se gerar um middleware Ginga, em um processo conhecido como derivac¸a˜ o. Para isto, o usu´ario deve acessar o reposit´orio do GingaCDN, escolher, a partir das caracter´ısticas de cada uma, as partes mais adequadas ao seu caso, e compil´a-las em um execut´avel. Com um n´umero grande de componentes, e sem uma forma unificada de descobrir os atributos de cada uma, esse processo se torna trabalhoso. Al´em do pr´oprio processo de compilac¸a˜ o, que n˜ao e´ trivial. Para facilitar isto foi criado o GingaInstance. O GingaInstance e´ uma ferramenta de derivac¸a˜ o de produtos baseada em modelos desenvolvida sobre a plataforma Eclipse 1 . Com ela, e´ poss´ıvel descobrir todos os componentes dispon´ıveis e suas caracter´ısticas, e derivar um middleware sem se preocupar com os detalhes t´ecnicos. Al´em disso, ela garante que os componentes selecionados s˜ao compat´ıveis. Os componentes podem ser incompat´ıveis por raz˜oes t´ecnicas, como terem sido projetados para plataformas diferentes, ou legais, como terem licenc¸as incompat´ıveis. Para verificar este segundo caso, o GingaInstancing usa o licc. O funcionamento e´ simples. Cada componente possui suas caracter´ısticas e recursos descritos em um arquivo XML. Dentre eles, sua licenc¸a. Ao selecionar os componentes desejados na interface do GingaInstancing, este executa o Licc passando as licenc¸as como argumento e lˆe seu estado de sa´ıda. Se ele executou com sucesso, continua o processo de derivac¸a˜ o de middleware. Caso contr´ario, avisa ao usu´ario e volta a` tela anterior [36]. 1 Ambiente

integrado de desenvolvimento dispon´ıvel em http://www.eclipse.org.

5.1 GingaInstancing

49

Figura 5.1: Tela do GingaInstancing mostrando que h´a uma incompatibilidade entre as licenc¸as dos componentes Na figura 5.1 pode-se ver uma tela do GingaInstancing que e´ mostrado quando e´ detectada alguma incompatibilidade entre as licenc¸as dos componentes. Da´ı a u´ nica opc¸a˜ o do usu´ario e desistir e tentar novamente mudando as partes escolhidas.

50

6

Trabalhos Relacionados

6.1

Black Duck TMProtex

E´ um sistema que identifica a origem das partes do c´odigo de um projeto, suas licenc¸as e verifica a compatibilidade entre elas. Para isto, ele usa a tecnologia Code Print

TM ,

que gera

uma assinatura para pedac¸os do c´odigo do software analisado, as compara com o KnowledgeBase, um reposit´orio de assinaturas de c´odigos conhecidos e suas respectivas licenc¸as, buscando encontrar a origem de cada parte do sistema e sua licenc¸a e, com a lista de todas as licenc¸as do projeto, verifica a compatibilidade entre elas [37] [38] [39] [40] [2] [3]. Como se pode ver, ele possui mais funcionalidades que o licc. Este s´o faz a u´ ltima parte desse processo: a verificac¸a˜ o da compatibilidade. Entretanto, esse sistema e´ uma soluc¸a˜ o comercial. Todos os softwares usados e os reposit´orios s˜ao privados, e seu custo pode ser proibitivo para pequenas e m´edias empresas. O licc, por ser livre, gratuito e usar tecnologias abertas, pode atingir uma gama maior de desenvolvedores.

6.2

Librock License Awareness System – Lidesc

E´ uma ferramenta livre que “automatiza o conhecimento e identificac¸a˜ o de licenc¸as e requisitos para redistribuic¸a˜ o dos softwares que vocˆe desenvolve ou obt´em.” [41] Ela possui um objetivo bem semelhante com o licc, com a adic¸a˜ o de uma funcionalidade de “carimbar” manualmente um c´odigo-fonte, de forma que a detecc¸a˜ o da licenc¸a de cada arquivo seja facilitada. Mas, ao contr´ario do licc, ele definiu uma REL pr´opria, com 65 atributos [42] (em contraste com os 10 do ccREL). Com eles, ele consegue uma granuladidade maior para definir a raz˜ao pela qual determinadas licenc¸as s˜ao incompat´ıveis. Entretanto, sua u´ ltima atualizac¸a˜ o foi em 2002, e criou uma REL pr´opria, n˜ao adotada por mais nenhuma organizac¸a˜ o. Assim, preferimos desenvolver uma nova ferramenta mais geral, que suportasse qualquer REL, inclusive a do pr´oprio Lidesc.

51

7

Conclus˜ao

O desenvolvimento distribu´ıdo de software gera uma s´erie de vantagens competitivas para as empresas, como diminuic¸a˜ o de custos e tempo de produc¸a˜ o. Mas tamb´em aumenta a importˆancia da gerˆencia da compatibilidade entre licenc¸as de software, visto que uma parte maior dos produtos da empresa s˜ao desenvolvidos por terceiros, que tˆem direitos autorais sobre suas criac¸o˜ es [1] [2] [3]. Este trabalho propˆos um modelo para verificac¸a˜ o de compatibilidade entre licenc¸as de software, uma parte do processo de gerˆencia de compatibilidade. Para isto, fez-se um levantamento do estado da arte das linguagens de express˜ao de direitos, das quais escolheu-se a ccREL. A partir dela, desenvolveu-se uma ferramenta que automatiza a verificac¸a˜ o de compatibilidade tanto com relac¸a˜ o ao relicenciamento quanto combinac¸a˜ o – o licc. Para validac¸a˜ o da ferramenta criou-se uma su´ıte de testes feita a partir das an´alises de compatibilidades por advogados da Creative Commons de Taiwan e Free Software Foundation. Al´em disso, fez-se um estudo de caso de uma ferramenta desenvolvida por terceiros que utiliza o licc para verificar a compatibilidade entre as licenc¸as dos componentes desenvolvidos no projeto GingaCDN. A principal contribuic¸a˜ o deste trabalho est´a na ferramenta livre, gratuita e extens´ıvel para verificac¸a˜ o de compatibilidade entre licenc¸as de software – licc, que possui as principais funcionalidades: • Leitura de arquivos locais ou via HTTP; • Interpretac¸a˜ o de licenc¸as descritas na linguagem ccREL usando RDF/XML; • Verificac¸a˜ o de compatibilidade entre licenc¸as com relac¸a˜ o a combinac¸a˜ o e/ou relicenciamento; • Arquitetura extens´ıvel com novas linguagens de express˜ao de direitos.

7.1 Trabalhos Futuros

7.1

52

Trabalhos Futuros

Como sugest˜ao para poss´ıveis trabalhos futuros, tem-se: • Extens˜ao do ccREL, de forma que consiga-se representar compatibilidades expl´ıcitas nos termos da licenc¸a e sob quais formas as licenc¸as lesser copyleft podem ser combinadas; • Extens˜ao do licc para aceitar licenc¸as descritas em outras linguagens de express˜ao de direitos; • Adaptac¸a˜ o do licc para detecc¸a˜ o de licenc¸as em c´odigos-fonte atrav´es de outras ferramentas; • Criac¸a˜ o de interface web onde se possa utilizar o licc sem necessidade de instalac¸a˜ o.

53

Referˆencias Bibliogr´aficas 1 SENGUPTA, B.; CHANDRA, S.; SINHA, V. A research agenda for distributed software development. In: Proceedings of the 28th international conference on Software engineering. New York, NY, USA: ACM, 2006. (ICSE ’06), p. 731–740. ISBN 1-59593-375-1. Dispon´ıvel em: . 2 SOFTWARE, B. D. The Business Case for Automating Open Source Code Management: How Managers Maximize ROI using Open Source in Software Development. [S.l.], 2009. Dispon´ıvel em: . 3 SEIDER, R.; VESCUSO, P. How to Increase Velocity and Value with Agile Development using Open Source. EUA, 2009. Dispon´ıvel em: . 4 BASSO, M. O direito internacional da propriedade intelectual. Porto Alegre: Livraria do Advogado, 2000. 5 TAIWAN, C. C. Creative Commons Licenses Compatibility Wizard. Dispon´ıvel em: . Acesso em: 13 dez. 2010. 6 FOUNDATION, F. S. How are the various GNU licenses compatible with each other? Dispon´ıvel em: . Acesso em: 13 dez. 2010. 7 GANDELMAN, M. Poder e conhecimento na economia global. Rio de Janeiro: Civilizac¸a˜ o Brasileira, 2004. 8 BARBOSA, D. B. Uma Introduc¸a˜ o a` Propriedade Intelectual. Rio de Janeiro: Lumen Juris, 2003. 9 PINHEIRO, P. P. Direito Digital. 2. ed. S˜ao Paulo: Saraiva, 2007. 10 INDUSTRIAL, I. N. da P. O que e´ Indicac¸a˜ o Geogr´afica? Dispon´ıvel em: . Acesso em: 9 dez. 2010. 11 BRASIL. Lei n ◦ 9.279, de 14 de maio de 1996. Regula direitos e obrigac¸o˜ es relativos a` propriedade industrial. Brasilia: Di´ario Oficial da Uni˜ao. Dispon´ıvel em: . 12 COELHO, F. U. Curso de Direito Comercial. 14. ed. S˜ao Paulo: Saraiva, 2010.

Referˆencias Bibliogr´aficas

54

13 BRASIL. Lei n ◦ 9.609, de 19 de fevereiro de 1998. Disp˜oe sobre a protec¸a˜ o da propriedade intelectual de programa de computador, sua comercializac¸a˜ o no Pa´ıs, e d´a outras providˆencias. Brasilia: Di´ario Oficial da Uni˜ao. Dispon´ıvel em: . 14 BRASIL. Lei n ◦ 7.232, de 29 de outubro de 1984. Disp˜oe sobre a Pol´ıtica Nacional de Inform´atica, e d´a outras providˆencias. Brasilia: Di´ario Oficial da Uni˜ao. Dispon´ıvel em: . 15 EUA. Trade Act of 1974. Washington: Federal Register. 16 BRASIL. Lei n ◦ 9.610, de 19 de fevereiro de 1998. Altera, atualiza e consolida a legislac¸a˜ o sobre direitos autorais e d´a outras providˆencias. Brasilia: Di´ario Oficial da Uni˜ao. Dispon´ıvel em: . 17 BRASIL. Decreto n ◦ 2.556, de 20 de abril de 1998. Regulamenta o registro previsto no art. 3 ◦ da Lei n ◦ 9.609, de 19 de fevereiro de 1998, que disp˜oe sobre a protec¸a˜ o da propriedade intelectual de programa de computador, sua comercializac¸a˜ o no Pa´ıs, e d´a outras providˆencias. Brasilia: Di´ario Oficial da Uni˜ao. Dispon´ıvel em: . 18 BRASIL. Lei n ◦ 8.078, de 11 de setembro de 1990. Disp˜oe sobre a protec¸a˜ o do consumidor e d´a outras providˆencias. Bras´ılia: Di´ario Oficial da Uni˜ao. Dispon´ıvel em: . 19 BRASIL. Decreto n ◦ 75.699, de 6 de maio de 1975. Promulga a Convenc¸a˜ o de Berna para a Protec¸a˜ o das Obras Liter´arias e Art´ısticas, de 9 de setembro de 1886, Revista em Paris, a 24 de julho de 1971. Brasilia: Di´ario Oficial da Uni˜ao. Dispon´ıvel em: . 20 MEEKER, H. J. The Open Source Alternative: Understanding Risks and Leveraging Opportunities. New Jersey: John Willey & Sons, Inc., 2008. 53 – 70 p. 21 CAMPOS, A. O que e´ software livre. Dispon´ıvel em: . Acesso em: 17 jun. 2009. 22 SILVEIRA, S. A. da et al. Software livre e inclus˜ao digital. S˜ao Paulo: Conrad, 2003. 23 FOUNDATION, F. S. V´arias licenc¸as e coment´arios sobre elas. Dispon´ıvel em: . Acesso em: 25 jul. 2009. 24 FOUNDATION, F. S. What is Copyleft? Dispon´ıvel em: . Acesso em: 15 nov. 2010. 25 SOFTWARE, B. D. Top 20 Most Commonly Used Licenses in Open Source Projects. Dispon´ıvel em: . Acesso em: 17 nov. 2010. 26 FOUNDATION, F. S. GNU Lesser General Public License. Dispon´ıvel em: . Acesso em: 2 dez. 2010.

Referˆencias Bibliogr´aficas

55

27 WIKIPEDIA. Common Development and Distribution License. Dispon´ıvel em: . Acesso em: 18 nov. 2010. 28 MYERS, R. NonCommercial Sharealike Is Not Copyleft. Dispon´ıvel em: . Acesso em: 18 nov. 2010. 29 WIKIPEDIA. Share-alike. Dispon´ıvel em: . Acesso em: 18 nov. 2010. 30 WIKIPEDIA. Wikia. Dispon´ıvel em: . Acesso em: 23 nov. 2010. 31 LINKSVAYER, M. Wikipedia + CC BY-SA = Free Culture Win! Dispon´ıvel em: . Acesso em: 23 nov. 2010. 32 COMMONS, C. Creative Commons Attribution-ShareAlike 3.0 Unported. Dispon´ıvel em: . Acesso em: 23 nov. 2010. 33 COYLE, K. Rights Expression Languages: A Report for the Library of Congress. Washington: Library of Congress, 2004. 34 WIKIPEDIA. Rights Expression Language. Dispon´ıvel em: . Acesso em: 23 nov. 2010. 35 COMMONS, C. ccREL: The Creative Commons Rights Expression Language. Dispon´ıvel em: . Acesso em: 21 out. 2010. 36 FILHO, S. L. de M. F. et al. Relat´orio T´ecnico RT-05 – Ferramenta de recuperac¸a˜ o de componentes, controle de vers˜ao e gerac¸a˜ o de releases do middleware Ginga. Jo˜ao Pessoa, 2010. 37 SOFTWARE, B. D. Black Duck Protex: Software Compliance Management Solution. [S.l.], 2009. Dispon´ıvel em: . 38 SOFTWARE, B. D. KnowledgeBase. Dispon´ıvel em: . Acesso em: 14 dez. 2010. 39 SOFTWARE, B. D. Best Practices for Managing Software Intellectual Property. [S.l.], 2007. Dispon´ıvel em: . 40 SOFTWARE, B. D. Software Compliance Management: Automating License Compliance in the New, Mixed-IP Development World. [S.l.], 2008. Dispon´ıvel em: . 41 CAVALIER, F. J. LIDESC: Librock License Awareness System. Dispon´ıvel em: . Acesso em: 14 dez. 2010. 42 CAVALIER, F. J. Creating a LIDESC TAGS string. Dispon´ıvel em: . Acesso em: 14 dez. 2010.

56

Gloss´ario Componente Unidade que encapsula sua implementac¸a˜ o e disponibiliza suas funcionalidads atrav´es de interfaces com contratos bem definidos. Interface E´ a forma da qual os componentes provˆem suas funcionalidades. Compilador Tipo de software que transforma o c´odigo-fonte feito em uma linguagem de programac¸a˜ o para c´odigo bin´ario, execut´avel por um computador. Biblioteca Tipo de software sem interface cujos usu´arios s˜ao outros programas, e n˜ao um ser humano. Ele provˆe um conjunto de funcionalidades prontas para serem usadas por outros sistemas, aumentando o reuso de c´odigo. Linkagem Parte do processo de compilac¸a˜ o onde cria-se uma ligac¸a˜ o entre o programa sendo compilado e as bibliotecas usadas. Linkagem est´atica Tipo de linkagem onde as bibliotecas s˜ao copiadas para o corpo do programa na compilac¸a˜ o, gerando um execut´avel u´ nico, com o software e todas suas dependˆencias. Linkagem dinˆamica Tipo de linkagem onde as bibliotecas s˜ao copiadas para o corpo do programa na execuc¸a˜ o. Desta forma, as dependˆencias do programa n˜ao est˜ao no mesmo execut´avel, mas em algum outro lugar no sistema.