Para tener una idea general de lo que es el licenciamiento de software así como sus aspectos y conceptos más importantes relacionados, aquí les dejo este esquema realizado por mi persona, el cual marca el inicio de una buena investigación para los interesados en indagar un poco más en este tema!!!
martes, 25 de mayo de 2010
4 categorías de licencias libres y abiertas...
El libro "Aspectos legales y de explotación del software libre" detallan cuatro (04) categorías de licencias libres y abiertas, las cuales son:
1. Las licencias libres con copyleft robusto: este caso pretende asegurar las cuatro libertades fundamentales del software libre en base a la figura del copyleft. Así como también permite que las modificaciones y los nuevos softwares sean distribuidos en las mismas condiciones.
2. Las licencias libres sin copyleft robusto: esta licencia se basa en que el código es fruto de las investigaciones y los trabajos universitarios financiados por el gobierno de los Estados Unidos (y los impuestos del pueblo americano), por lo tanto, debe ser de acceso libre, protegiendo lo que llamaríamos aquí los “derechos morales” de los autores por la simple obligación de mantener los avisos de autoría (copyright notice).
3. Las licencias libres sin copyleft: Estas licencias son incompatibles con la GPL, en el sentido de que no se puede integrar material de estos programas en un programa o su obra derivada bajo la GPL porque las licencias sobre estos materiales incluyen obligaciones que son más restrictivas que la GPL
4. Las licencias “seudo-libres”: Estas son licencias creadas por empresas que intentan beneficiarse del modelo de desarrollo libre.
Es importante tener bien claro las diferencias entre ellas, aunque debo confesar que son fáciles de confundir por sus ciertas similitudes, pero a pesar de ello, todas persiguen detalles diferentes.
1. Las licencias libres con copyleft robusto: este caso pretende asegurar las cuatro libertades fundamentales del software libre en base a la figura del copyleft. Así como también permite que las modificaciones y los nuevos softwares sean distribuidos en las mismas condiciones.
2. Las licencias libres sin copyleft robusto: esta licencia se basa en que el código es fruto de las investigaciones y los trabajos universitarios financiados por el gobierno de los Estados Unidos (y los impuestos del pueblo americano), por lo tanto, debe ser de acceso libre, protegiendo lo que llamaríamos aquí los “derechos morales” de los autores por la simple obligación de mantener los avisos de autoría (copyright notice).
3. Las licencias libres sin copyleft: Estas licencias son incompatibles con la GPL, en el sentido de que no se puede integrar material de estos programas en un programa o su obra derivada bajo la GPL porque las licencias sobre estos materiales incluyen obligaciones que son más restrictivas que la GPL
4. Las licencias “seudo-libres”: Estas son licencias creadas por empresas que intentan beneficiarse del modelo de desarrollo libre.
Es importante tener bien claro las diferencias entre ellas, aunque debo confesar que son fáciles de confundir por sus ciertas similitudes, pero a pesar de ello, todas persiguen detalles diferentes.
Aspecto importante de las Licencias de Software Libre...
Es importante recalcar que una licencia que requiera que las versiones modificadas no sean libres, no se puede considerar como una licencia libre.
La mayoría de las licencias de software libre están basadas en el copyright, y existen límites en los tipos de requisitos que pueden ser impuestos a través del copyright. Si una licencia basada en el copyright respeta la libertad en las formas antes mencionadas, es poco probable tener otro tipo de problema que no hayamos anticipado (a pesar de que esto ocurre ocasionalmente). Sin embargo, algunas licencias de software libre están basadas en contratos, y los contratos pueden imponer un rango mucho más grande de restricciones posibles. Esto significa que existen muchas maneras posibles de que tal licencia pueda ser inaceptablemente restrictiva y que no sea libre. Esta información fue extraida de la página de GNU.
La mayoría de las licencias de software libre están basadas en el copyright, y existen límites en los tipos de requisitos que pueden ser impuestos a través del copyright. Si una licencia basada en el copyright respeta la libertad en las formas antes mencionadas, es poco probable tener otro tipo de problema que no hayamos anticipado (a pesar de que esto ocurre ocasionalmente). Sin embargo, algunas licencias de software libre están basadas en contratos, y los contratos pueden imponer un rango mucho más grande de restricciones posibles. Esto significa que existen muchas maneras posibles de que tal licencia pueda ser inaceptablemente restrictiva y que no sea libre. Esta información fue extraida de la página de GNU.
Licencia de Código Abierto....
Según ABAX Asesores, para que una licencia sea considerada “licencias de código abierto” deben cumplir con los siguientes requisitos mínimos:
1.- Debe permitirse la libre redistribución del software.
2.- El código fuente debe estar disponible.
3.- Debe permitirse la modificación del software y la creación de programas derivados. 4.- Debe garantizarse la integridad del programa original. Esto puede hacerse exigiendo que la distribución de cualquier modificación se haga de forma separada, o que cualquier modificación o programa derivado sea distribuido con un nombre o versión diferente.
5.- No se debe discriminar a ninguna persona o grupo de personas.
6.- Debe permitirse el uso del software para cualquier fin.
7.- La licencia debe ser distribuida junto con el software. La licencia debe aplicarse por igual a todos los que utilizan el programa.
8.- La licencia deberá ser siempre la misma, sin importar si el software es incluido dentro de una distribución o paquete específico.
9.- La licencia no debe aplicar restricciones sobre otros programas.
10.- La licencia debe ser tecnológicamente neutral
1.- Debe permitirse la libre redistribución del software.
2.- El código fuente debe estar disponible.
3.- Debe permitirse la modificación del software y la creación de programas derivados. 4.- Debe garantizarse la integridad del programa original. Esto puede hacerse exigiendo que la distribución de cualquier modificación se haga de forma separada, o que cualquier modificación o programa derivado sea distribuido con un nombre o versión diferente.
5.- No se debe discriminar a ninguna persona o grupo de personas.
6.- Debe permitirse el uso del software para cualquier fin.
7.- La licencia debe ser distribuida junto con el software. La licencia debe aplicarse por igual a todos los que utilizan el programa.
8.- La licencia deberá ser siempre la misma, sin importar si el software es incluido dentro de una distribución o paquete específico.
9.- La licencia no debe aplicar restricciones sobre otros programas.
10.- La licencia debe ser tecnológicamente neutral
martes, 11 de mayo de 2010
Software Libre en Venezuela
Pueden visitar este link para que conozcan las novedades respecto al Software Libre que se ha realizado en nuestro país.
http://www.softwarelibre.gob.ve/
http://www.softwarelibre.gob.ve/
Herramientas para construir Diagramas UML
Existen muchas herramientas para construir un diagrama UML, entre las más conocidas se encuentran: ArgoUML, FUJABA, StarUML que se distribuye con licencia GPL, mUML, RhapsodyModeler, ObjecteeringUML, UML Studio, Dia, DOME, Poseidon, entre otros.
La única herramienta que he tenido la oportunidad de utilizar es ArgoUML la cual es escrita en Java y publicada bajo la Licencia BSD. Entre las últimas características que han sacado de mejoras en las versiones es la compatibilidad con AndroMDA, han sido corregidos cientos de bugs detectados en todas las versiones previas, mayor facilidad en la creación del modelo, entre otras. En mi experiencia propia, me parece que es muy amigable y sencillo de utilizar.
Me gustaría tener la oportunidad de utilizar otras herramientas para compararlas con mis experiencias propias, además de las diferencias encontradas en internet y de las que indicaron mis compañeros.
Aquí les dejo una página que muestra gáficamente la aplicación y las funcionalidades básicas a seguir para la construcción del Diagrama UML.
http://trevinca.ei.uvigo.es/~jgarcia/TO/usoArgoUML/index.html
La única herramienta que he tenido la oportunidad de utilizar es ArgoUML la cual es escrita en Java y publicada bajo la Licencia BSD. Entre las últimas características que han sacado de mejoras en las versiones es la compatibilidad con AndroMDA, han sido corregidos cientos de bugs detectados en todas las versiones previas, mayor facilidad en la creación del modelo, entre otras. En mi experiencia propia, me parece que es muy amigable y sencillo de utilizar.
Me gustaría tener la oportunidad de utilizar otras herramientas para compararlas con mis experiencias propias, además de las diferencias encontradas en internet y de las que indicaron mis compañeros.
Aquí les dejo una página que muestra gáficamente la aplicación y las funcionalidades básicas a seguir para la construcción del Diagrama UML.
http://trevinca.ei.uvigo.es/~jgarcia/TO/usoArgoUML/index.html
Importancia del Diagrama UML
El diagrama de UML es muy importante por varias razones:
1) Posee características más visuales que programáticas, por lo cual facilita la comunicación entre los analistas de la aplicación y los conocedores de las reglas de negocio (como lo menciona Ginestá Marc y González Álvaro en su libro “Ingeniería del Software en entorno de Software Libre”, en el segundo punto de lo que permite hacer un modelado visual). Esto reduce las posibilidad de desarrollar softwares que no cumplan con las expectactivas del cliente, ya que en la trasmisión de los requisitos iniciales del cliente al programador no se captó lo que el usuario quiere realmente, o no hubo una buena explicación por parte del cliente.
2) Facilita el proceso de desarrollo del software para el programador, ya que anteriormente logró visualizar de manera gráfica lo que quiere plasmar en códigos, es más fácil traducir de este concepto visual que directamente de los requerimientos del cliente.
3) Determina la mejor manera de solucionar la situación propuesta (requerimientos --> sistema), ya que realizando el Diagrama de UML se puede visualizar de mejor manera las acciones que suelen repetirse, los objetos, clases, métodos, funciones, entre otros que son similares y de esta manera se acorta el tiempo de desarrollo y se pone en práctica la "reutilización", término muy bien visto en esta época de libre información - software libre y de programación orientada a objetos.
4) Facilita la documentación del sistema desarrollado, el cual debe pasar de igual forma por su proceso de QA.
1) Posee características más visuales que programáticas, por lo cual facilita la comunicación entre los analistas de la aplicación y los conocedores de las reglas de negocio (como lo menciona Ginestá Marc y González Álvaro en su libro “Ingeniería del Software en entorno de Software Libre”, en el segundo punto de lo que permite hacer un modelado visual). Esto reduce las posibilidad de desarrollar softwares que no cumplan con las expectactivas del cliente, ya que en la trasmisión de los requisitos iniciales del cliente al programador no se captó lo que el usuario quiere realmente, o no hubo una buena explicación por parte del cliente.
2) Facilita el proceso de desarrollo del software para el programador, ya que anteriormente logró visualizar de manera gráfica lo que quiere plasmar en códigos, es más fácil traducir de este concepto visual que directamente de los requerimientos del cliente.
3) Determina la mejor manera de solucionar la situación propuesta (requerimientos --> sistema), ya que realizando el Diagrama de UML se puede visualizar de mejor manera las acciones que suelen repetirse, los objetos, clases, métodos, funciones, entre otros que son similares y de esta manera se acorta el tiempo de desarrollo y se pone en práctica la "reutilización", término muy bien visto en esta época de libre información - software libre y de programación orientada a objetos.
4) Facilita la documentación del sistema desarrollado, el cual debe pasar de igual forma por su proceso de QA.
Diagrama UML
Permite establecer los requerimientos del usuario y estructuras necesarias para plasmar un sistema de software previo al proceso, como se diría coloquialmente, de "echar código".
Es diagrama es semejante a los planos en un construcción de un edificio, por ejemplo. Que podría comenzar construyendo el edificio con la idea que tiene en la "mente" el Ingeniero Civil pero sin tener unos planos previamente realizados, es MUY probable que esa construcción no quede estable, no contemple la seguridad necesaria, entre otros aspectos. Igual sucede con el desarrollo de software, muchas veces queremos comenzar a "echar código" sin detenernos a analizar la situación a ver cual sería la mejor manera de hacerlo.
Es diagrama es semejante a los planos en un construcción de un edificio, por ejemplo. Que podría comenzar construyendo el edificio con la idea que tiene en la "mente" el Ingeniero Civil pero sin tener unos planos previamente realizados, es MUY probable que esa construcción no quede estable, no contemple la seguridad necesaria, entre otros aspectos. Igual sucede con el desarrollo de software, muchas veces queremos comenzar a "echar código" sin detenernos a analizar la situación a ver cual sería la mejor manera de hacerlo.
Suscribirse a:
Entradas (Atom)