1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
#use wml::debian::template title="Comparação de Licenças de Software"
#use wml::debian::translation-check translation="2bd18a67682540fb7c79d49a858ca9bcfaa704ed"
<P><STRONG>******Este documento está em desenvolvimento*******</STRONG>
<P>Aqueles que acompanham o Software Livre tendem a desenvolver opiniões
muito fortes sobre licenças. Os iniciantes não se preocupam com elas
já que estão mais preocupados em acabar seu trabalho e não entendem
as implicações de longo prazo de se escolher software com uma licença
ao invés de outro (é duvidoso que haja muitas pessoas que entendam as nuances
do licenciamento que não têm opiniões fortes sobre o assunto).
<P>Através dos anos, um número de licenças ganharam proeminência pois
dão aos autores de software o tipo de controle sobre sua criação que
a maioria dos desenvolvedores desejam. É ainda comum encontrar software
que não tem copyright visível ou que contém uma licença única desenvolvida
pelo autor. A última pode ser muito incômoda para os distribuidores de
software (tanto on-line quanto pessoas que criam CDs) pois muitas dessas
licenças contém <a href="#mistakes">erros comuns</a> que tornam o software
difícil de distribuir.
<P>O que segue é uma lista de licenças de software Livres (Abertas) comuns
e alguns pontos bons e ruins de cada.
Apenas os pontos relevantes à discussão são mostrados. Também, muitos
pontos são listados sob o título "BOM/MAU". Esses são pontos que podem
ser bons ou maus, dependendo do seu ponto de vista.
<UL>
<LI>A <A HREF="https://www.gnu.org/">Licença Pública Geral GNU (GPL)</A>.
<BR>
<B>SUMÁRIO:</B> código fonte deve ser disponibilizado, software pode ser
vendido; trabalhos derivados devem usar a mesma licença
<BR>
<B>BOM:</B> Há uma boa razão para essa ser a licença mais usada para software
Livre (Aberto). Ela faz um bom trabalho protegendo os direitos dos desenvolvedores
de software e a disponibilidade de código garante que os usuários não terão
de se preocupar em perder suporte no futuro.
<BR>
<B>BOM/MAU:</B> Software que é lançada usando a GPL não pode ser incorporado
em software comercial. Se isto é atualmente uma coisa ruim depende do seu
ponto de vista. As pessoas que desenvolvem software comercial geralmente
se sentem frustradas quando há uma solução disponível que não pode ser usada
por causa de conflitos no licenciamento. Claro, não há nada os impedindo de
contatar o autor e ver se podem comprar uma versão usando uma licença diferente.
A maioria das pessoas que lançam seu software usando a GPL não considera essas
restrições ruins porque ela permite aos outros usarem e melhorarem o software
enquanto previne (para todos os propósitos práticos) que outros façam dinheiro
a partir do seu trabalho duro sem sua permissão.
<LI>Licença Artística
<A HREF="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</A>.
<BR>
<B>SUMÁRIO:</B>
<BR>
<B>BOM:</B>
<BR>
<B>MAU:</B>
<LI><A HREF="https://opensource.org/licenses/BSD-3-Clause">Licença estilo BSD</A>.
<BR>
<B>SUMÁRIO:</B> Binários e código fonte devem conter a licença; anúncios devem
reconhecer os desenvolvedores listados na licença
<BR>
<B>BOM/MAU:</B> Companhias que querem um executável disponível (possivelmente
gratuitamente) sem lançar o código fonte geralmente gostam dessa licença.
Um bom exemplo é uma companhia que quer lançar um driver para uma placa de
vídeo. Os seguidores do Software Livre prefeririam que a empresa lançasse as
especificações de hardware de qualquer modo. Se o desenvolvimento dos drivers
para o XFree86 é indicativo, os melhores drivers são aqueles escritos com o
fonte disponível. As companhias estão apenas fazendo seus produtos parecerem
ruins lançando drivers proprietários que são lentos e bugados. Eles podem também
economizar custos de desenvolvimento deixando que outros desenvolvam o driver
para eles.
<BR>
<B>BOM/MAU:</B> Qualquer um pode pegar o fonte, modificar e lançar o resultado
sem lançar as mudanças do fonte. Se você acha que isso é bom ou mau, é uma
preferência pessoal.
</UL>
<HR>
<P><A NAME="mistakes">Alguns erros comuns em licenças escritos pelos desenvolvedores</A>:
<UL>
<LI>Ou não permitir ou restringir a venda por lucro do software.
Isso torna difícil distribuir o software em CD. As pessoas normalmente
cometem o erro de usar termos que não são bem definidos, como 'custo
razoável'. É melhor simplesmente usar uma das licenças mencionadas
acima pois elas conseguem o mesmo objetivo sem fazer uso de tais frases.
Por exemplo, ao permitir que qualquer um distribua o software, a GPL mantém
os custos baixos por forças normais do mercado. Se alguém está vendendo um
CD com uma margem de lucro alta ele não durará muito tempo até que os
competidores entrem no mercado e vendam por um preço mais baixo.
<BR>Nota: Licença Artística usa o termo 'custo de cópia razoável', mas
qualifica o termo na tentativa de torná-lo menos vago.
<LI>Não permitir distribuição de versões modificadas do software.
Isso se opõe à distribuição de software por certos grupos. Por exempo, já que
o Debian distribui software compilado, é normalmente necessário modificar o
fonte para conseguir compilá-lo ou para fazer com que ele seja compatível com
os <A HREF="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/">FSSTND</A>.
Mas ao fazer isso, não estamos portanto permitidos a distribuí-lo.
<LI>Requerer que todas as mudanças feitas ao software sejam reportadas ao autor.
Apesar de ser uma boa idéia relatar mudanças/melhoras para o autor para que elas
possam ser distribuídas mais largamente, fazer disso um requerimento pode causar
problemas. Como muitas pessoas sabem onde elas estarão em 5 anos?
Simplesmente mude isso para 'Quaisquer mudanças deveriam ser relatadas ao autor'.
A maioria das pessoas o farão.
<BR>Esta cláusula é normalmente incluída para prevenir o desenvolvimento de
projetos "galho". A história mostrou que, contanto que o desenvolvimento
no código original não pare, os "galhos" só prosperarão se alguma outra força
dirigir a divisão.
<LI>Dizer que o software é de domínio público mas então incluir bloqueios (como não
permitir a venda por lucro). Ou algo está no domínio público ou não está -
não há meio termo. Tais licenças são insignificantes e é possível que as
condições extras não se segurariam num tribunal.
</UL>
|
