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
117
118
119
120
121
122
123
124
125
|
#use wml::debian::template title="Comparación de las Licencias de Software"
#use wml::debian::translation-check translation="a2d057aa44562ddcc643379de20b7fc2c0c7f9e4"
<P><STRONG>******Este documento está en desarrollo*******</STRONG>
<P>Las personas que han estado alrededor del software de fuentes abiertas,
también llamado software libre, tienden
a desarrollar unas opiniones muy fuertes acerca de las licencias. Los
que se inician no se preocupan tanto de ésto dado que están más preocupados en terminar
el trabajo que están haciendo y no entienden las implicaciones a largo plazo
de elegir un software con unas licencias sobre otro (es dudoso que muchas
personas que entiendan las pegas de licenciar no tengan fuertes opiniones sobre la materia).
<P>A lo largo de los años un número de licencias han ganado importancia
al dar a los autores de software el tipo de control sobre sus
creaciones que la mayoría de los desarrolladores desean. Aún es común
encontrar software que no tiene copyright visible o que contiene una
licencia única desarrollada por el autor. La último puede ser bastante
fastidiosa para los distribuidores de software (tanto en línea como
las personas que hacen CD) dado que muchas de éstas licencias
contienen <A HREF="#mistakes">errores comunes</A> que hacen a éste
software difícil de distribuir.
<P>Lo que sigue es una lista de licencias de software libre comunes y
una lista de puntos buenos y malos de cada una.
Sólo se muestran los puntos referentes a la discusión de
licencias. Muchos se listan bajo el encabezamiento de
"BUENO/MALO". Algunos de éstos pueden resultar buenos o malos, dependiendo de su
punto de vista.
<UL>
<LI>La <A HREF="https://www.gnu.org/">Licencia Pública General GNU (GPL)</A>.
<BR>
<B>RESUMEN:</B> el código fuente debe estar disponible; el software se puede
vender; los proyectos derivados deben usar la misma licencia.
<BR>
<B>BUENO:</B> Esta es una buena razón por la que ésta es la licencia
para software libre más usada. Hace un buen trabajo
protegiendo los derechos del desarrollador de software y la
disponibilidad de código fuente garantiza que los usuarios no tendrán
que preocuparse de perder apoyo en un futuro.
<BR>
<B>BUENO/MALO:</B> El software distribuido usando la licencia GPL
no puede incorporarse dentro de software comercial. Que ésto sea realmente malo
depende de su punto de vista. Las personas que desarrollan software
comercial se sienten frecuentemente frustradas cuando hay una solución disponible que
no puede usarse porque entra en conflicto con la licencia. Por
supuesto, no hay nada que les impida contactar con el autor y ver si
pueden comprar una versión que tenga otra licencia. Cualquiera que
distribuya software usando la GPL no considera estas restricciones
malas, porque permite a otros usar y mejorar su software, mientras impide
(para todos los propósitos prácticos) que otros usuarios hagan dinero de
su duro trabajo sin su permiso.
<LI>Licencia Artística
<A HREF="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</A>.
<BR>
<B>RESUMEN:</B>
<BR>
<B>BUENO:</B>
<BR>
<B>MALO:</B>
<LI><A HREF="https://opensource.org/licenses/BSD-3-Clause">Licencia al estilo de BSD</A>.
<BR>
<B>RESUMEN:</B> Los binarios y código fuente deben contener la
licencia; los anuncios publicitarios deben dar crédito a los
desarrolladores listados en la licencia.
<BR>
<B>BUENO/MALO:</B> A las compañías que quieren que los ejecutables
estén disponibles (posiblemente gratis) sin entregar el código fuente
les gusta generalmente esta licencia. Un buen ejemplo es una compañía
que quiere distribuir una controladora para una tarjeta gráfica. Las
personas que promocionan el uso de código de fuentes abiertas preferirían que la
compañías dieran las especificaciones del hardware. Si el desarrollo de
los controladores para XFree86 es significativo, las mejores controladoras
son las escritas con código fuente disponible. Las compañías sólo
consiguen hacer parecer malos a sus productos al dar controladoras
propietarias que son lentas y están llenas de errores. También pueden
ahorrar costes de desarrollo al dejar que otros les desarrollen el controlador.
<BR>
<B>BUENO/MALO:</B> Cualquiera puede coger el código, modificarlo,
y distribuir el resultado sin distribuir los cambios. Que ésto sea
bueno o malo depende de sus preferencias personales.
</UL>
<HR>
<P><A name="mistakes">Algunos errores comunes en licencias escritas por uno mismo</A>:
<UL>
<LI>No permitir, o restringir, ventas con beneficios del software.
Esto hace difícil distribuir el software en CD. Se comete
habitualmente el error de usar términos que no están bien definidos,
como 'coste razonable'. Es mejor, simplemente, el uso de una de las
licencias arriba indicadas dado que consiguen lo mismo sin recurrir a tales frases.
Por ejemplo, al permitir que cualquiera distribuya el software, la GPL
mantiene los costes bajos debido a las fuerzas usuales del mercado. Si
alguien vende un CD con un margen de beneficios alto no tardará mucho
tiempo en llegar competidores al mercado y vender por un precio menor.
<BR>Nota: la Licencia Artística usa el término 'Reasonable copying fee'
(cargo de copia razonable), pero califica el término en
un intento de hacerlo menos indefinido.
<LI>No permitir la distribución de versiones modificadas del software.
Esto impide la distribución del software por ciertos grupos. Por
ejemplo, dado que Debian distribuye software compilado, a menudo es
necesario modificar el código fuente para hacerlo compilar o adecuarlo al
<A HREF="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/">FSSTND</A>.
Pero al hacer esto, entonces no estamos autorizados a distribuirlo.
<LI>Requerir que todos los cambios del software sean informados al autor.
Mientras que es una buena idea avisar de los cambios/mejoras al
autor para que puedan ser distribuidos ampliamente, hacer de esto una
obligación puede causar problemas. ¿Cuántas personas saben dónde
van a estar dentro de cinco años?
Se debe cambiar simplemente a 'Cualquier cambio en el software
conviene que sea indicado al autor'. La mayor parte de la gente lo hará.
<BR>Esta cláusula generalmente se incluye para evitar que se desarrollen otros
proyectos a partir de éste. La historia ha demostrado que mientras el
desarrollo del código original no se pare, las ramificaciones del mismo sólo
sobreviven si hay otras fuerzas obligando a la partición.
<LI>Indicar que el software es de dominio público, y luego añadir restricciones
(como que no puede ser vendido para obtener beneficios). O algo es de dominio
público o no lo es - no hay término medio. Estas licencias no tiene sentido
y es posible que las condiciones adicionales no puedan ser sostenidas ante un tribunal.
</UL>
|
