Metodologa de diseo

Y10K
Versin 0.1 18-11-2006
Copyright 2006 Ignasi Fosch Alonso (ifosch@uoc.edu), Javier Arellano Roig (jarellano@uoc.edu)..
Se concede permiso para copiar, distribuir y/o modificar este documento bajo los trminos de la Licencia de Documentacin Libre de
GNU, Versin 1.2 o cualquier otra versin posterior publicada por la Free Software Foundation; sin Secciones Invariantes ni Textos de
Cubierta Delantera ni Textos de Cubierta Trasera. Una copia de la licencia est incluida en la seccin titulada GNU Free Documentation
License.
1. Sobre la Metodologa de diseo
Este documento pretende determinar las metodologas de diseo que se utilizarn para la realizacin del
proyecto AyeAye. Dado que lo aqu descrito es un intento de aplicar unas tcnicas y metodologas al
desarrollo de software libre, es posible que sirva para otros proyectos que se desarrollen posteriormente, por
lo que los desarrolladores de este proyecto hemos decidido publicar y mantener las normas que hemos
seguido para el diseo.
2. Programacin Extrema
2.1. Definicin
La programacin extrema es una metodologa de desarrollo del software, enmarcada dentro de las
metodologas giles. Las caractersticas principales son:
Desarrollo en iteraciones, en las que se aaden mejoras, generando las distintas versiones.
Pruebas unitarias continuas, comprobando que la aplicacin mantenga sus funcionalidades.
Programacin en parejas, haciendo que cada tarea sea desarrolle en parejas, permitiendo que el
cdigo se discuta y revise mientras se programa.
Interaccin entre los desarrolladores y el usuario, que ha de ser lo suficientemente frecuente para
economizar el esfuerzo de ambas partes.
Correccin de los errores antes de cada iteracin, haciendo que la versin resultante de una
iteracin sea estable.
Refactorizacin del cdigo, haciendolo ms legible y mantenible, pero garantizando su
funcionamiento manteniendo las pruebas unitarias.
Propiedad del cdigo compartida, de modo que cualquier integrante del proyecto pueda modificar
cdigo hecho por otro. Otra vez la existencia de errores se comprueba mediante las pruebas.
Simplicidad del diseo, haciendo que sea fcil aadir las nuevas funcionalidades.
2.2. Informacin
Hay mucha informacin sobre programacin extrema en Internet. Como fuente de informacin hemos usado
la pgina 'Extreme Programming: A Gentle Introduction' que ofrece una visin completa y comparada de la
programacin extrema, sin adentrarse en los entresijos ms detallados. Otra fuente muy interesante, y en
castellano, es la wiki de Programacin extrema, que tiene una lista de enlaces muy recomendable. De esta
lista, cabe destacar la web de Ron Jeffries que contiene un interesante surtido de recursos relacionados.
2.3. Programacin extrema y software libre
En la mayor parte de la informacin disponible se habla del usuario como cliente. Esto resulta del hecho de
que la programacin extrema se ha probado extensamente en entornos comerciales de desarrollo a medida.
Esto, desde ciertos puntos de vista, nos hizo dudar un poco de su posible aplicacin a un proyecto de
software libre, pero encontramos algunas referencias a ambas metodologas relacionadas, como en un
artculo de Andrew McKinlay. Tambin observamos que el famoso libro de Eric S. Raymond, 'La Catedral y
el Bazar' era una obra de referencia en muchos de los crculos de la programacin extrema. Estos dos
factores nos convencieron de que aplicar las tcnicas de desarrollo de la programacin extrema a un
proyecto de software libre no slo era posible sino que, almenos en aparencia, sera muy provechoso.
3. Una metodologa gil para el proyecto
3.1. El usuario y los relatos de usuario (User Stories)
Uno de los roles ms importantes en programacin extrema es el usuario o cliente, como se le denomina en
mucha documentacin existente. Este usuario tiene, entre otras, una funcin muy importante que es la de
describir las funcionalidades en lo que se denomina relatos de usuario. Estos relatos son descripciones de
las funcionalidades, quizs identificadas por un nmero y/o fecha. No deben ser en gran detalle, pero cada
una debe identificar una funcionalidad independiente, de modo que se pueda valorar como una nica tarea
a realizar por los desarrolladores. Un ejemplo de relato sera algo como: La aplicacin ser capaz de
gestionar una relacin de dispositivos.
En nuestro proyecto, dado que, almenos por ahora, no hay usuarios que escriban los relatos, los
escribiremos nosotros mismos, aprovechando nuestra situacin laboral que nos pone en la necesidad de
una herramienta como AyeAye. Para registrar los relatos utilizaremos el blog, aadiendo los relatos, ya
delimitados, a la versin en curso. Para ello, dispondremos de una categora para cada versin dentro de la
cual existir una rama para los relatos.
3.2. Una prueba para cada funcionalidad
Otra de las funciones principales del usuario es definir pruebas para guiar el desarrollo. Un detalle que
puede parecer curioso, es que estas pruebas se deben tener preparadas antes de empezar el desarrollo, de
modo que los desarrolladores no puedan olvidarse de codificar algn detalle. En realidad existen dos tipos
de pruebas, por un lado las que realiza el usuario y por otro las realizadas por los desarrolladores. Las
primeras se llaman pruebas de aceptacin y las segundas pruebas unitarias.
En nuestro caso, estas pruebas las vamos a escribir los desarrolladores, sin intervencin directa del usuario,
an cuando pudiera existir. Para definir lo que se probar en cada una de las versiones, se utilizar una
nueva entrada en el blog, dentro de una categora paralela a la de los relatos. El cdigo de las pruebas se
dejar en una carpeta Tests dentro del SVN.
3.3. El juego de la planificacin
Segn la fuente, los pasos de la planificacin de un proyecto en programacin extrema varan mucho, pero
tienen algunos puntos clave iguales:
1. Primero, se determinan los relatos, se analizan y se valora el coste de producirlo. Si el relato es
demasiado largo, hay que partirlo en relatos ms cortos.
2. A continuacin, se entra dentro de una iteracin, que consiste en la eleccin de los relatos a
implementar, se implementan y se prueban hasta que cumplen las expectativas de los relatos
definidas por las pruebas.
3. Tras superar todas las pruebas, la iteracin se finaliza, liberando una versin del software, y se
vuelve al primer paso, el de recopilar y valorar los relatos.
De entre las diferentes puntualizaciones que se hacen en las fuentes de informacin sobre XP, hay algunas
que detallan las tres posibles situaciones en las que un relato no pueda ser valorado, y plantean, a parte de
la de que el relato sea demasiado grande, dos muy interesantes: Que el desarrollador no comprenda el
relato, caso en el que deber hablar con el usuario para detallarlo y conocer el alcance del problema
planteado; y que el desarollador desconozca la viabilidad tcnica de una implementacin, caso en el que
deber realizar un ensayo (spike) para comprobar la tcnica correcta para implementarlo. Este ensayo no
puede llevar demasiado tiempo, slo debe servir para encontrar el camino de la implementacin.
En nuestro caso, este procedimiento de planificacin lo adaptaremos a nuestra situacin: Existirn los
relatos que se presentarn para cada versin, cerrando as la 'release planning' y publicndolos en el blog,
se prepararn las pruebas, definidas en el blog, y se colgarn del SVN, aadindolas a las de posibles
versiones anteriores. Una vez hecho esto, se crear el cdigo nuevo necesario y se modificar el existente
segn convenga (siempre siguiendo las ideas de la refactorizacin, que se comentan ms adelante). Se
realizarn las pruebas y una vez se cumplan todos los relatos y las pruebas den resutlados vlidos, se
cerrar una versin y se iniciar la definicin de los relatos de la siguiente.
3.4. Programar de dos en dos
Este concepto, que resulta de mucha utilidad en equipo grandes de desarrolladores, consiste en que los
equipos se dividan en grupos de dos, donde cada grupo trabaje con un solo ordenador sobre una sola tarea,
incrementando su productividad en ms que el doble de cada uno de los componentes del grupo por
separado. Adems, segn la fuente, existe la ventaja de que si se juntan dos desarrolladores con diferentes
niveles de experiencia, el ms novato puede aprender mucho del experimentado, en ciertas condiciones de
trabajo.
Este concepto de la programacin extrema no lo podremos aplicar correctamente, dado que nuestro equipo,
que inicialmente se compone de dos personas, no puede trabajar simultneamente. Recordemos, adems,
que una de las principales caractersticas de los proyectos de software libre es que se trata de muchos
programadores conectados a la red que no tienen coincidencia ni espacial ni temporal, necesariamente, por
lo tanto, este apartado quedar descartado como de uso obligatorio, aunque, si es necesario y posible, nos
podramos reunir para realizar alguna tarea especialemente compleja o importante.
3.5. Prueba, programa y prueba
El trmino de integracin continua define, en XP, el hecho de que antes y despus de cada generacin y
modificacin de cdigo, las pruebas deben quedar completamente superadas. De hecho, esto es ms una
especia de subproducto de la refactorizacin. No obstante, hay que destacar que las pruebas a verificar
deben ser las requeridas por la versin en curso. Este concepto, pues, aplica ms a cambios en mdulos o
unidades refactorizadas de versiones anteriores que en mdulos o unidades nuevas.
Por nuestra parte, este requerimiento deber cumplirse en cada modificacin del rbol. En otras palabras,
un aadido no se puede considerar completo si no supera, como mnimo, las mismas pruebas que superaba
antes de bajarlo.
3.6. Refactorizar segn se necesite
Uno de los aspectos de la programacin extrema ms importantes, tanto que se usa incluso fuera de ella, es
la refactorizacin. Esta tcnica consiste en ir modificando el cdigo de un mdulo sin que las
funcionalidades iniciales de ste se vean afectadas a ojos de quien las requiere. Un ejemplo muy sencillo es
el de una funcin que multiplicase dos nmeros a y b. En una primera versin podra hacerlo ab, pero en
una refactorizacin de su mdulo, podra hacerlo ba; sin modificar su resultado, se ha modificado su
comportamiento.
Dado que estas refactorizaciones se realizan en cada versin, es evidente que slo con incluir las nuevas
funcionalidades de los relatos, habr muchas probabilidades de refactorizar. Podramos decir que este
concepto lo vamos a mantener tal cual lo hemos definido.
3.7. Libera pronto, libera a menudo
El concepto de liberaciones pequeas, o iteraciones cortas, es muy simple, ya que consiste en sacar las
versiones tan pronto y rpido como sea posible, siempre que cumplan las funcionalidades especificadas sin
incluir fallos.
Nuestra situacin de estudiantes y trabajadores implica que la liberacin a menudo sea algo un tanto difcil
de concretar. En muchas de las fuentes comprobadas, se mencionan perodos no superiores a 3 semanas,
pero cuando se hace referencia a proyectos de software libre, estos perodos se alargan un poco, dado que
los desarrolladores estn separados espacial y temporalmente, y que sus jerarquas son un poco
anrquicas. Lo nico que podemos hacer es intentar que las versiones se cierren lo ms pronto posible, lo
cual, teniendo en cuenta el punto 3.5, esto debera suceder.
3.8. Haciendo metforas del software
Uno de los conceptos ms importantes para potenciar la comunicacin es el uso de metforas del sistema.
Las metforas son expresiones en lenguaje ambiguo que sirven para dar una idea ms o menos aproximada
de los elementos que lo componen.
En nuestro caso, aunque no crearemos un glosario, iremos creando las metforas de sistema creando
relatos o incluyndolas en los relatos.
3.9. Simplicidad
Es muy importante destacar que uno de los pilares que hacen eficiente la programacin extrema es
mantener los diseos y las implementaciones simples. Esto permite evitar esfuerzo innecesario y facilita el
anlisis posterior al refactorizar. Una frase muy interesante que describe este concepto es Pon lo que
necesitas cuando lo necesites, de Kent Beck en 'Extreme Programming Explained'.
Nuestro proyecto va a tener mdulos que previsiblemente evolucionen mucho de una versin a otra, por esto
precisamente debemos procurar que nuestro diseo tenga siempre presente la simplicidad no adelantando
relatos futuros.
3.10. El proyecto es responsabilidad de todos los desarrolladores
Este concepto, que podra parecer utpico a primera vista, es muy importante pues al mismo tiempo que
otorga el derecho a cualquier desarrollador de modificar el cdigo de otro, tambin le otorga el deber de
comprobar que las pruebas activas sigan funcionando.
Nuestro proyecto, como cualquier proyecto de software libre permitir esta libertad, permitiendo consultar a
travs del blog los cambios que se proponen, para evitar perder tiempo en deshacer entuertos. Hay que
destacar especialmente que esta libertad est supeditada a mantener la simplicidad del cdigo.
3.11. Convencin al codificar
Como en la escritura de documentacin, la creacin de cdigo debe tener en cuenta que quien lo lea debe
poder entenderlo, por lo que se suelen crear convenciones sobre cmo est escrito el cdigo. As, es
imposible reconocer el autor de un cdigo slo con leerlo.
Nuestro proyecto incorpora unas convenciones relativamente estrictas que deben regir el formato y estilo de
todo el cdigo del proyecto.
3.12. Semanas de 40 horas
Uno de los puntos ms interesantes para el entorno laboral de los desarrolladores, as como para su
productividad, es el compromiso de la programacin extrema de mantener un nivel y ritmo de trabajo
aceptable y compatible con la jornada laboral estndar. Es muy frecuente que los componentes de equipos
de programacin dediquen horas y horas a la creacin de cdigo slo por cumplir las fechas calculadas.
Nuestro caso, como ya se ha comentado en el apartado de liberacin de versiones, es un poco crtico, dado
que el tiempo dedicado a nuestros estudios y trabajos limitan bastante el tiempo que podamos dedicar
dentro de los mrgenes mnimos de productividad. Cabe destacar que este concepto tambin es uno de los
puntos flojos de la programacin extrema cuando se ajusta al funcionamiento de un proyecto de software
libre.
Apndice A. GNU Free Documentation License
Versin 1.2, Noviembre 2002
This is an unofficial translation of the GNU Free Documentation
License into Spanish. It was not published by the Free Software
Foundation, and does not legally state the distribution terms for
documentation that uses the GNU FDL -- only the original English
text of the GNU FDL does that. However, we hope that this
translation will help Spanish speakers understand the GNU FDL
better.
sta es una traduccin no oficial de la GNU Free Document License a
Espaol (Castellano). No ha sido publicada por la Free Software
Foundation y no establece legalmente los trminos de distribucin
para trabajos que usen la GFDL (slo el texto de la versin
original en Ingls de la GFDL lo hace). Sin embargo, esperamos que
esta traduccin ayude los hispanohablantes a entender mejor la
GFDL. La versin original de la GFDL esta disponible en la [1]Free
Software Foundation.
Esta traduccin est basada en una de la versin 1.1 de Igor Tmara
y Pablo Reyes. Sin embargo la responsabilidad de su interpretacin
es de Joaqun Seoane.
Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 59
Temple Place, Suite 330, Boston, MA 02111-1307 USA. Se permite la
copia y distribucin de copias literales de este documento de
licencia, pero no se permiten cambios[2][1].
_________________________________________________________________
A.1. PREMBULO
El propsito de esta Licencia es permitir que un manual, libro de
texto, u otro documento escrito sea libre en el sentido de libertad:
asegurar a todo el mundo la libertad efectiva de copiarlo y
redistribuirlo, con o sin modificaciones, de manera comercial o no. En
segundo trmino, esta Licencia proporciona al autor y al editor[3][2]
una manera de obtener reconocimiento por su trabajo, sin que se le
considere responsable de las modificaciones realizadas por otros.
Esta Licencia es de tipo copyleft, lo que significa que los trabajos
derivados del documento deben a su vez ser libres en el mismo sentido.
Complementa la Licencia Pblica General de GNU, que es una licencia
tipo copyleft diseada para el software libre.
Hemos diseado esta Licencia para usarla en manuales de software
libre, ya que el software libre necesita documentacin libre: un
programa libre debe venir con manuales que ofrezcan la mismas
libertades que el software. Pero esta licencia no se limita a manuales
de software; puede usarse para cualquier texto, sin tener en cuenta su
temtica o si se publica como libro impreso o no. Recomendamos esta
licencia principalmente para trabajos cuyo fin sea instructivo o de
referencia.
_________________________________________________________________
A.2. APLICABILIDAD Y DEFINICIONES
Esta Licencia se aplica a cualquier manual u otro trabajo, en
cualquier soporte, que contenga una nota del propietario de los
derechos de autor que indique que puede ser distribuido bajo los
trminos de esta Licencia. Tal nota garantiza en cualquier lugar del
mundo, sin pago de derechos y sin lmite de tiempo, el uso de dicho
trabajo segn las condiciones aqu estipuladas. En adelante la palabra
Documento se referir a cualquiera de dichos manuales o trabajos.
Cualquier persona es un licenciatario y ser referido como Usted.
Usted acepta la licencia si copia. modifica o distribuye el trabajo de
cualquier modo que requiera permiso segn la ley de propiedad
intelectual.
Una Versin Modificada del Documento significa cualquier trabajo que
contenga el Documento o una porcin del mismo, ya sea una copia
literal o con modificaciones y/o traducciones a otro idioma.
Una Seccin Secundaria es un apndice con ttulo o una seccin
preliminar del Documento que trata exclusivamente de la relacin entre
los autores o editores y el tema general del Documento (o temas
relacionados) pero que no contiene nada que entre directamente en
dicho tema general (por ejemplo, si el Documento es en parte un texto
de matemticas, una Seccin Secundaria puede no explicar nada de
matemticas). La relacin puede ser una conexin histrica con el tema
o temas relacionados, o una opinin legal, comercial, filosfica,
tica o poltica acerca de ellos.
Las Secciones Invariantes son ciertas Secciones Secundarias cuyos
ttulos son designados como Secciones Invariantes en la nota que
indica que el documento es liberado bajo esta Licencia. Si una seccin
no entra en la definicin de Secundaria, no puede designarse como
Invariante. El documento puede no tener Secciones Invariantes. Si el
Documento no identifica las Secciones Invariantes, es que no las
tiene.
Los Textos de Cubierta son ciertos pasajes cortos de texto que se
listan como Textos de Cubierta Delantera o Textos de Cubierta Trasera
en la nota que indica que el documento es liberado bajo esta Licencia.
Un Texto de Cubierta Delantera puede tener como mucho 5 palabras, y
uno de Cubierta Trasera puede tener hasta 25 palabras.
Una copia Transparente del Documento, significa una copia para lectura
en mquina, representada en un formato cuya especificacin est
disponible al pblico en general, apto para que los contenidos puedan
ser vistos y editados directamente con editores de texto genricos o
(para imgenes compuestas por puntos) con programas genricos de
manipulacin de imgenes o (para dibujos) con algn editor de dibujos
ampliamente disponible, y que sea adecuado como entrada para
formateadores de texto o para su traduccin automtica a formatos
adecuados para formateadores de texto. Una copia hecha en un formato
definido como Transparente, pero cuyo marcaje o ausencia de l haya
sido diseado para impedir o dificultar modificaciones posteriores por
parte de los lectores no es Transparente. Un formato de imagen no es
Transparente si se usa para una cantidad de texto sustancial. Una
copia que no es Transparente se denomina Opaca.
Como ejemplos de formatos adecuados para copias Transparentes estn
ASCII puro sin marcaje, formato de entrada de Texinfo, formato de
entrada de LaTeX, SGML o XML usando una DTD disponible pblicamente, y
HTML, PostScript o PDF simples, que sigan los estndares y diseados
para que los modifiquen personas. Ejemplos de formatos de imagen
transparentes son PNG, XCF y JPG. Los formatos Opacos incluyen
formatos propietarios que pueden ser ledos y editados nicamente en
procesadores de palabras propietarios, SGML o XML para los cules las
DTD y/o herramientas de procesamiento no estn ampliamente
disponibles, y HTML, PostScript o PDF generados por algunos
procesadores de palabras slo como salida.
La Portada significa, en un libro impreso, la pgina de ttulo, ms
las pginas siguientes que sean necesarias para mantener legiblemente
el material que esta Licencia requiere en la portada. Para trabajos en
formatos que no tienen pgina de portada como tal, Portada significa
el texto cercano a la aparicin ms prominente del ttulo del trabajo,
precediendo el comienzo del cuerpo del texto.
Una seccin Titulada XYZ significa una parte del Documento cuyo ttulo
es precisamente XYZ o contiene XYZ entre parntesis, a continuacin de
texto que traduce XYZ a otro idioma (aqu XYZ se refiere a nombres de
seccin especficos mencionados ms abajo, como Agradecimientos,
Dedicatorias , Aprobaciones o Historia. Conservar el Ttulo de tal
seccin cuando se modifica el Documento significa que permanece una
seccin Titulada XYZ segn esta definicin[4][3] .
El Documento puede incluir Limitaciones de Garanta cercanas a la nota
donde se declara que al Documento se le aplica esta Licencia. Se
considera que estas Limitaciones de Garanta estn incluidas, por
referencia, en la Licencia, pero slo en cuanto a limitaciones de
garanta: cualquier otra implicacin que estas Limitaciones de
Garanta puedan tener es nula y no tiene efecto en el significado de
esta Licencia.
_________________________________________________________________
A.3. COPIA LITERAL
Usted puede copiar y distribuir el Documento en cualquier soporte, sea
en forma comercial o no, siempre y cuando esta Licencia, las notas de
copyright y la nota que indica que esta Licencia se aplica al
Documento se reproduzcan en todas las copias y que usted no aada
ninguna otra condicin a las expuestas en esta Licencia. Usted no
puede usar medidas tcnicas para obstruir o controlar la lectura o
copia posterior de las copias que usted haga o distribuya. Sin
embargo, usted puede aceptar compensacin a cambio de las copias. Si
distribuye un nmero suficientemente grande de copias tambin deber
seguir las condiciones de la seccin 3.
Usted tambin puede prestar copias, bajo las mismas condiciones
establecidas anteriormente, y puede exhibir copias pblicamente.
_________________________________________________________________
A.4. COPIADO EN CANTIDAD
Si publica copias impresas del Documento (o copias en soportes que
tengan normalmente cubiertas impresas) que sobrepasen las 100, y la
nota de licencia del Documento exige Textos de Cubierta, debe incluir
las copias con cubiertas que lleven en forma clara y legible todos
esos Textos de Cubierta: Textos de Cubierta Delantera en la cubierta
delantera y Textos de Cubierta Trasera en la cubierta trasera. Ambas
cubiertas deben identificarlo a Usted clara y legiblemente como editor
de tales copias. La cubierta debe mostrar el ttulo completo con todas
las palabras igualmente prominentes y visibles. Adems puede aadir
otro material en las cubiertas. Las copias con cambios limitados a las
cubiertas, siempre que conserven el ttulo del Documento y satisfagan
estas condiciones, pueden considerarse como copias literales.
Si los textos requeridos para la cubierta son muy voluminosos para que
ajusten legiblemente, debe colocar los primeros (tantos como sea
razonable colocar) en la verdadera cubierta y situar el resto en
pginas adyacentes.
Si Usted publica o distribuye copias Opacas del Documento cuya
cantidad exceda las 100, debe incluir una copia Transparente, que
pueda ser leda por una mquina, con cada copia Opaca, o bien mostrar,
en cada copia Opaca, una direccin de red donde cualquier usuario de
la misma tenga acceso por medio de protocolos pblicos y
estandarizados a una copia Transparente del Documento completa, sin
material adicional. Si usted hace uso de la ltima opcin, deber
tomar las medidas necesarias, cuando comience la distribucin de las
copias Opacas en cantidad, para asegurar que esta copia Transparente
permanecer accesible en el sitio establecido por lo menos un ao
despus de la ltima vez que distribuya una copia Opaca de esa edicin
al pblico (directamente o a travs de sus agentes o distribuidores).
Se solicita, aunque no es requisito, que se ponga en contacto con los
autores del Documento antes de redistribuir gran nmero de copias,
para darles la oportunidad de que le proporcionen una versin
actualizada del Documento.
_________________________________________________________________
A.5. MODIFICACIONES
Puede copiar y distribuir una Versin Modificada del Documento bajo
las condiciones de las secciones 2 y 3 anteriores, siempre que usted
libere la Versin Modificada bajo esta misma Licencia, con la Versin
Modificada haciendo el rol del Documento, por lo tanto dando licencia
de distribucin y modificacin de la Versin Modificada a quienquiera
posea una copia de la misma. Adems, debe hacer lo siguiente en la
Versin Modificada:
* A. Usar en la Portada (y en las cubiertas, si hay alguna) un
ttulo distinto al del Documento y de sus versiones anteriores
(que deberan, si hay alguna, estar listadas en la seccin de
Historia del Documento). Puede usar el mismo ttulo de versiones
anteriores al original siempre y cuando quien las public
originalmente otorgue permiso.
* B. Listar en la Portada, como autores, una o ms personas o
entidades responsables de la autora de las modificaciones de la
Versin Modificada, junto con por lo menos cinco de los autores
principales del Documento (todos sus autores principales, si hay
menos de cinco), a menos que le eximan de tal requisito.
* C. Mostrar en la Portada como editor el nombre del editor de la
Versin Modificada.
* D. Conservar todas las notas de copyright del Documento.
* E. Aadir una nota de copyright apropiada a sus modificaciones,
adyacente a las otras notas de copyright.
* F. Incluir, inmediatamente despus de las notas de copyright, una
nota de licencia dando el permiso para usar la Versin Modificada
bajo los trminos de esta Licencia, como se muestra en la Adenda
al final de este documento.
* G. Conservar en esa nota de licencia el listado completo de las
Secciones Invariantes y de los Textos de Cubierta que sean
requeridos en la nota de Licencia del Documento original.
* H. Incluir una copia sin modificacin de esta Licencia.
* I. Conservar la seccin Titulada Historia, conservar su Ttulo y
aadirle un elemento que declare al menos el ttulo, el ao, los
nuevos autores y el editor de la Versin Modificada, tal como
figuran en la Portada. Si no hay una seccin Titulada Historia en
el Documento, crear una estableciendo el ttulo, el ao, los
autores y el editor del Documento, tal como figuran en su Portada,
aadiendo adems un elemento describiendo la Versin Modificada,
como se estableci en la oracin anterior.
* J. Conservar la direccin en red, si la hay, dada en el Documento
para el acceso pblico a una copia Transparente del mismo, as
como las otras direcciones de red dadas en el Documento para
versiones anteriores en las que estuviese basado. Pueden ubicarse
en la seccin Historia. Se puede omitir la ubicacin en red de un
trabajo que haya sido publicado por lo menos cuatro aos antes que
el Documento mismo, o si el editor original de dicha versin da
permiso.
* K. En cualquier seccin Titulada Agradecimientos o Dedicatorias,
Conservar el Ttulo de la seccin y conservar en ella toda la
sustancia y el tono de los agradecimientos y/o dedicatorias
incluidas por cada contribuyente.
* L. Conservar todas las Secciones Invariantes del Documento, sin
alterar su texto ni sus ttulos. Nmeros de seccin o el
equivalente no son considerados parte de los ttulos de la
seccin.
* M. Borrar cualquier seccin titulada Aprobaciones. Tales secciones
no pueden estar incluidas en las Versiones Modificadas.
* N. No cambiar el ttulo de ninguna seccin existente a
Aprobaciones ni a uno que entre en conflicto con el de alguna
Seccin Invariante.
* O. Conservar todas las Limitaciones de Garanta.
Si la Versin Modificada incluye secciones o apndices nuevos que
califiquen como Secciones Secundarias y contienen material no copiado
del Documento, puede opcionalmente designar algunas o todas esas
secciones como invariantes. Para hacerlo, aada sus ttulos a la lista
de Secciones Invariantes en la nota de licencia de la Versin
Modificada. Tales ttulos deben ser distintos de cualquier otro ttulo
de seccin.
Puede aadir una seccin titulada Aprobaciones, siempre que contenga
nicamente aprobaciones de su Versin Modificada por otras fuentes
--por ejemplo, observaciones de peritos o que el texto ha sido
aprobado por una organizacin como la definicin oficial de un
estndar.
Puede aadir un pasaje de hasta cinco palabras como Texto de Cubierta
Delantera y un pasaje de hasta 25 palabras como Texto de Cubierta
Trasera en la Versin Modificada. Una entidad solo puede aadir (o
hacer que se aada) un pasaje al Texto de Cubierta Delantera y uno al
de Cubierta Trasera. Si el Documento ya incluye un textos de cubiertas
aadidos previamente por usted o por la misma entidad que usted
representa, usted no puede aadir otro; pero puede reemplazar el
anterior, con permiso explcito del editor que agreg el texto
anterior.
Con esta Licencia ni los autores ni los editores del Documento dan
permiso para usar sus nombres para publicidad ni para asegurar o
implicar aprobacin de cualquier Versin Modificada.
_________________________________________________________________
A.6. COMBINACIN DE DOCUMENTOS
Usted puede combinar el Documento con otros documentos liberados bajo
esta Licencia, bajo los trminos definidos en la seccin 4 anterior
para versiones modificadas, siempre que incluya en la combinacin
todas las Secciones Invariantes de todos los documentos originales,
sin modificar, listadas todas como Secciones Invariantes del trabajo
combinado en su nota de licencia. As mismo debe incluir la Limitacin
de Garanta.
El trabajo combinado necesita contener solamente una copia de esta
Licencia, y puede reemplazar varias Secciones Invariantes idnticas
por una sola copia. Si hay varias Secciones Invariantes con el mismo
nombre pero con contenidos diferentes, haga el ttulo de cada una de
estas secciones nico aadindole al final del mismo, entre
parntesis, el nombre del autor o editor original de esa seccin, si
es conocido, o si no, un nmero nico. Haga el mismo ajuste a los
ttulos de seccin en la lista de Secciones Invariantes de la nota de
licencia del trabajo combinado.
En la combinacin, debe combinar cualquier seccin Titulada Historia
de los documentos originales, formando una seccin Titulada Historia;
de la misma forma combine cualquier seccin Titulada Agradecimientos,
y cualquier seccin Titulada Dedicatorias. Debe borrar todas las
secciones tituladas Aprobaciones.
_________________________________________________________________
A.7. COLECCIONES DE DOCUMENTOS
Puede hacer una coleccin que conste del Documento y de otros
documentos liberados bajo esta Licencia, y reemplazar las copias
individuales de esta Licencia en todos los documentos por una sola
copia que est incluida en la coleccin, siempre que siga las reglas
de esta Licencia para cada copia literal de cada uno de los documentos
en cualquiera de los dems aspectos.
Puede extraer un solo documento de una de tales colecciones y
distribuirlo individualmente bajo esta Licencia, siempre que inserte
una copia de esta Licencia en el documento extrado, y siga esta
Licencia en todos los dems aspectos relativos a la copia literal de
dicho documento.
_________________________________________________________________
A.8. AGREGACIN CON TRABAJOS INDEPENDIENTES
Una recopilacin que conste del Documento o sus derivados y de otros
documentos o trabajos separados e independientes, en cualquier soporte
de almacenamiento o distribucin, se denomina un agregado si el
copyright resultante de la compilacin no se usa para limitar los
derechos de los usuarios de la misma ms all de lo que los de los
trabajos individuales permiten. Cuando el Documento se incluye en un
agregado, esta Licencia no se aplica a otros trabajos del agregado que
no sean en s mismos derivados del Documento.
Si el requisito de la seccin 3 sobre el Texto de Cubierta es
aplicable a estas copias del Documento y el Documento es menor que la
mitad del agregado entero, los Textos de Cubierta del Documento pueden
colocarse en cubiertas que enmarquen solamente el Documento dentro del
agregado, o el equivalente electrnico de las cubiertas si el
documento est en forma electrnica. En caso contrario deben aparecer
en cubiertas impresas enmarcando todo el agregado.
_________________________________________________________________
A.9. TRADUCCIN
La Traduccin es considerada como un tipo de modificacin, por lo que
usted puede distribuir traducciones del Documento bajo los trminos de
la seccin 4. El reemplazo las Secciones Invariantes con traducciones
requiere permiso especial de los dueos de derecho de autor, pero
usted puede aadir traducciones de algunas o todas las Secciones
Invariantes a las versiones originales de las mismas. Puede incluir
una traduccin de esta Licencia, de todas las notas de licencia del
documento, as como de las Limitaciones de Garanta, siempre que
incluya tambin la versin en Ingls de esta Licencia y las versiones
originales de las notas de licencia y Limitaciones de Garanta. En
caso de desacuerdo entre la traduccin y la versin original en Ingls
de esta Licencia, la nota de licencia o la limitacin de garanta, la
versin original en Ingls prevalecer.
Si una seccin del Documento est Titulada Agradecimientos,
Dedicatorias o Historia el requisito (seccin 4) de Conservar su
Ttulo (Seccin 1) requerir, tpicamente, cambiar su ttulo.
_________________________________________________________________
A.10. TERMINACIN
Usted no puede copiar, modificar, sublicenciar o distribuir el
Documento salvo por lo permitido expresamente por esta Licencia.
Cualquier otro intento de copia, modificacin, sublicenciamiento o
distribucin del Documento es nulo, y dar por terminados
automticamente sus derechos bajo esa Licencia. Sin embargo, los
terceros que hayan recibido copias, o derechos, de usted bajo esta
Licencia no vern terminadas sus licencias, siempre que permanezcan en
total conformidad con ella.
_________________________________________________________________
A.11. REVISIONES FUTURAS DE ESTA LICENCIA
De vez en cuando la Free Software Foundation puede publicar versiones
nuevas y revisadas de la Licencia de Documentacin Libre GNU. Tales
versiones nuevas sern similares en espritu a la presente versin,
pero pueden diferir en detalles para solucionar nuevos problemas o
intereses. Vea http://www.gnu.org/copyleft/.
Cada versin de la Licencia tiene un nmero de versin que la
distingue. Si el Documento especifica que se aplica una versin
numerada en particular de esta licencia o cualquier versin posterior,
usted tiene la opcin de seguir los trminos y condiciones de la
versin especificada o cualquiera posterior que haya sido publicada
(no como borrador) por la Free Software Foundation. Si el Documento no
especifica un nmero de versin de esta Licencia, puede escoger
cualquier versin que haya sido publicada (no como borrador) por la
Free Software Foundation.
_________________________________________________________________
A.12. ADENDA: Cmo usar esta Licencia en sus documentos
Para usar esta licencia en un documento que usted haya escrito,
incluya una copia de la Licencia en el documento y ponga el siguiente
copyright y nota de licencia justo despus de la pgina de ttulo:
Copyright (c) AO SU NOMBRE. Se concede permiso para copiar,
distribuir y/o modificar este documento bajo los trminos de la
Licencia de Documentacin Libre de GNU, Versin 1.2 o cualquier
otra versin posterior publicada por la Free Software Foundation;
sin Secciones Invariantes ni Textos de Cubierta Delantera ni Textos
de Cubierta Trasera. Una copia de la licencia est incluida en la
seccin titulada GNU Free Documentation License.
Si tiene Secciones Invariantes, Textos de Cubierta Delantera y Textos
de Cubierta Trasera, reemplace la frase sin ... Trasera por esto:
siendo las Secciones Invariantes LISTE SUS TTULOS, siendo los
Textos de Cubierta Delantera LISTAR, y siendo sus Textos de
Cubierta Trasera LISTAR.
Si tiene Secciones Invariantes sin Textos de Cubierta o cualquier otra
combinacin de los tres, mezcle ambas alternativas para adaptarse a la
situacin.
Si su documento contiene ejemplos de cdigo de programa no triviales,
recomendamos liberar estos ejemplos en paralelo bajo la licencia de
software libre que usted elija, como la Licencia Pblica General de
GNU (GNU General Public License), para permitir su uso en software
libre.
Notes
[5][1]
sta es la traduccin del Copyright de la Licencia, no es el Copyright
de esta traduccin no autorizada.
[6][2]
La licencia original dice publisher, que es, estrictamente, quien
publica, diferente de editor, que es ms bien quien prepara un texto
para publicar. En castellano editor se usa para ambas cosas.
[7][3]
En sentido estricto esta licencia parece exigir que los ttulos sean
exactamente Acknowledgements, Dedications, Endorsements e History, en
ingls.
References
1. http://www.gnu.org/copyleft/fdl.html
2. file://localhost/home/jsp/academico/cursos/doctorado/sobre/repositorio/curso-
sobre/trunk/introsobre/gfdles.html#FTN.AEN11
3. file://localhost/home/jsp/academico/cursos/doctorado/sobre/repositorio/curso-
sobre/trunk/introsobre/gfdles.html#FTN.AEN17
4. file://localhost/home/jsp/academico/cursos/doctorado/sobre/repositorio/curso-
sobre/trunk/introsobre/gfdles.html#FTN.AEN54
5. file://localhost/home/jsp/academico/cursos/doctorado/sobre/repositorio/curso-
sobre/trunk/introsobre/gfdles.html#AEN11
6. file://localhost/home/jsp/academico/cursos/doctorado/sobre/repositorio/curso-
sobre/trunk/introsobre/gfdles.html#AEN17
7. file://localhost/home/jsp/academico/cursos/doctorado/sobre/repositorio/curso-
sobre/trunk/introsobre/gfdles.html#AEN54