Cuáles son los retos y oportunidades del SL

El software libre garantiza a todo el mundo el acceso al código fuente, la posibilidad de modificarlo y consecuentemente la participación en el proceso de creación. También garantiza la posibilidad de distribución a cualquier usuario o empresa del software. Todos tenemos los mismos derechos sobre el software libre, lo que crea un entorno de libre competencia, que es beneficioso para las propias empresas y usuarios. Cualquier empresa tiene las mismas oportunidades de competir que cualquier otra persona o empresa del resto del mundo.

Este Software, permite al usuario, la modificación o desarrollo de los mismos. Va más allá, no sólo hace referencia al libre acceso al código fuente; sino que establecen las condiciones de distribución, a fin de cumplir una serie de criterios que garanticen la evolución, perennidad y libre obtención de la misma y todas aquellas desarrolladas en base a ésta.

En cuanto a lo profesional la implementación de Software Libre plantea un futuro muy prometedor para aquellas personas que sepan programar, traducir, utilizar un programa, enseñar, etc. Si tenemos que elegir entre pagar una licencia de software a un coloso informático o darle trabajo directamente a una persona, es de esperar que nos volquemos a la segunda alternativa.

En relación a los retos y desafíos:

a) Lograr la aceptación y  disposición de los usuarios para utilizar el nuevo ambiente,

b) Disponer del compromiso de los directivos del ente gubernamental para incentivar la migración,

c) Formación adecuada para minimizar la resistencia al cambio,

d) Investigación y desarrollo permanente para ofrecer todo tipo de aplicaciones en SL, e) Seguir asumiendo desde el Estado el impulso y desarrollo de experiencias exitosas en el uso y aplicación en la APN del SL con estándares abiertos.

A estos retos añadiría el desarrollo de estrategias que permitan elevar la confianza de los usuarios a fin de que estén dispuestos a migrar sus equipos, aplicaciones y datos a plataformas basadas en tecnologías libres.

Hay varios aspectos que hacen del software libre una excelente oportunidad de expansión en nuestro país:

• Un gran número de instituciones en manos del Estado Venezolano.
• El decreto 3390, que impulsa el uso prioritario de Software Libre.
• Abre el camino hacia la innovación tecnológica, lo que permite el surgimiento de nuevas y mejores aplicaciones y tecnologías, que serian imposibles de crear en ambientes privativos.
• La posibilidad de desarrollar, mejorar e integrar las aplicaciones de software en un tiempo mucho menor.
• La cooperación para el logro de los objetivos, es uno de los principios que apalancan a este movimiento.
• Los costos se ven reducidos por no ser necesarios el pago de licencias. Este ahorro se traduce en inversión en otras áreas de interés.
• El estado actual de las instituciones, que atraviesan una etapa de crecimiento tecnológico que ha originado gran demanda de soluciones de software.
• La independencia de los proveedores. Al usar Software Libre, es posible realizar modificaciones, sin necesidad de un proveedor específico, solo se requiere personal con conocimientos en el tema

Un reto en el ámbito académico está apoyado en la visión de Richard Stallman, considera al estudiante como un ser integral, el reto es enseñarle la importancia de la libertad y debe guiarlo para que haga uso de ella, es despertar el interés de la filosofía de usar software libre. Hacerle entender que debe estudiar hasta donde su curiosidad lo lleve, profundizar en el conocimiento, esto fomenta la investigación, y los valores inherentes a la colaboración, responsabilidad, solidaridad, entre otros.

Las escuelas deben enseñar software libre, lo cual le da la oportunidad de que las instituciones educativas deben: economizar en costos millonarios en la adquisición de licencias por cada herramienta utilizada; las posibilidades de tener estudiantes mejor preparados, con menos dependencia al software privativo, y  mayor conocimiento de la tecnología; los estudiantes pueden estudiar las aplicaciones por tener acceso al código fuente, además de estimular la innovación tecnológica (libertad de modificar y compartir); la documentación (manuales y tutoriales) utilizado por un docente o estudiante puede ser distribuido a los demás sin problema de legalidad alguna con la intención de dar publicidad a la filosofía de software libre. También se considera como una oportunidad, la facilidad y capacidad para adaptar las aplicaciones para que cumplan con las necesidades particulares de las instituciones. Esta última es una ventaja que es aplicable a todos los ámbitos.

Los retos en el ámbito social, se tiene que dar a conocer el software libre más allá de los especialistas y de los usuarios expertos. Se debe trabajar para presentar el software libre como una alternativa de trabajo en el mundo empresarial y en el hogar, pues la mayoría se presentan como grandes consumidores de tecnologías propietarias. A nivel empresarial se debe lograr que el  software libre sea una solución completa, que se de uso a los programas de escritorio por la mayoría de los trabajadores de las empresas, como los software de desarrollo, los software que almacenan la información (archivos planos, bases de datos, etc) pasando por los sistemas operativos. Es inculcar la filosofía del software libre a la forma de trabajo de la organización.

Según Gladys Rodríguez, podremos encontrar las siguientes oportunidades y desafíos:

Oportunidades:

• Permiten a las naciones acceder a tecnología de primer nivel
• Están al alcance de individuos y organizaciones como herramientas de trabajo para los estudios y negocios
• Significan para el Estado ahorros millonarios en la adquisición de licencias
• Eliminan las barreras presupuestarias
• Posibilitan el desarrollo tecnológico para los países, al acceder al diseño de los
• programas se puede aprender de estos La intención es precisamente esa, que la independencia y autonomía no pueda depender de terceros
• Las aplicaciones son fácilmente auditadas.

Desafío:

• Como individuos, nos proporciona la opción de decidir libremente si lo queremos utilizar o escoger un software más costoso, conociendo las ventajas y desventajas que esto supone; y
• Desde los gobiernos, estos tienen la obligación de escoger la opción que sea mejor para el interés de su país, a sabiendas de que hace unos pocos años atrás el software libre no era una opción viable y hoy es una realidad. (Sanchez, 2008) 

Fuentes:

http://www.udem.edu.co/NR/rdonlyres/D1F726A4-CE75-4A15-966B-C67718C06F49/10934/Artculo6Softwarelibre.pdf

http://www.softwarelibre.venezuela.net.ve/index.php?entry=entry060613-073051

http://www.cepep.org.ve/documentos/cursos/tecnologia_educativa/Software%20Libre%20en%20Vzla%20y%20Soberania%20Tecnologica.pdf

http://www.lared.com.ve/detalle.php?id_noticia=880

MIGRACION A SL

En un proceso de migración es indispensable conocer hacia donde queremos llegar y de donde estamos partiendo. Muchos de los usuarios de SP (usuarios comunes, desarrolladores, administradores de servidores, redes, etc) estarán acostumbrados a una gran cantidad de aplicaciones desde su suite ofimática, hasta sus IDE's de programación, pasando por todos los software multimedia que hacen del uso de su equipo una tarea sencilla y amigable.

Al momento de tener que hacer dicha migración se plantearan muchas dudas y naturalmente se presentara la resistencia al cambio puesto que tienen que dejar su "circulo de confianza" con los software conocidos para partir a un mundo de aplicaciones en un SO diferente y no necesariamente con las mismas funcionalidades. Esto representa invertir tiempo en re-aprender a utilizar estas nuevas herramientas y en el peor de los casos optar por vías alternas dado que no existiese alguna alternativa libre.

En el libro de Fernando de la Rosa y Federico Heinz se exponen nueve (9) aspectos importantes relacionados con la migración del software propietario al software libre. Siendo estos los siguientes:

1.      Lo ideal sería partir de cero, pero al hablar de migración se hace referencia que estas pasando de la existencia de un software propietario para pasar a un software libre. Y estas migraciones poseen sus características especiales y problemáticas específicas.

2.      Considerar la serie de inconvenientes que se presentan a lo largo de la migración, ya que los productos privados vienen diseñados para evitar la migración y lograr una “fidelización forzosa” con el cliente.

3.      Para la lograr una migración con éxito se debe contar con un buen equipo que apoye el cambio, así como del apoyo de los usuarios. Es importante antes del cambio realizar charlas explicativas del por qué de la migración. Involucrar positivamente a los usuarios es fundamental.

4.      Realizar un claro diagnóstico de la situación de partida. Que incluye: arquitectura del sistema, configuración de la red, hardware y software utilizado, además de las características de los usuarios del sistema.

5.      Definir con la misma precisión la situación que esperamos encontrar al terminar la migración

6.      Justificar el por qué de la migración

7.      Describir el plan de migración

8.      Tener en consideración el procesamiento de los datos

9.      Contar con un equipo técnico que pueda brindar asesoramiento a los usuarios luego de la migración.

El objetivo principal de la migración es que al finalizar todos los equipos de la red, tanto clientes como servidores, ejecuten prácticamente sólo software libre.   Todo esto con el fin de lograr que la Migración sea lo más transparente posible para el usuario

Al momento de migrar a SL hay que tener presente las siguientes consideraciones técnicas:

·       Migrar desktops es probablemente lo más complicado de todo porque entra en juego el factor humano.

·       Hay que incentivar a los usuarios a aprender nuevas cosas. Un elemento para convencerlos en esforzarse por migrar es que van a alimentar su CV, emitir un certificado por las capacitaciones recibidas es algo muy importante. Detectar a los mas hábiles en la capacitación, promoverlos a soporte de su área, es otra amanera de incentivarlos.

·       El usuario debe perder el miedo a lo desconocido, migrar por etapas, grupos o personas individuales progresivamente es algo muy bueno para esto.

·       Ver que sus jefes usan los sistemas libres es un elemento de importancia (predicar con el ejemplo), de otra manera no querrán migrar.

·       El usuario siempre se pregunta si su archivo en “office” va a poder ser leído en el nuevo software (el 90% de su data personal es de este tipo), la respuesta es si; instalarle una suite ofimática libre antes de migrar para que lo compruebe es buena idea.

·       Los usuarios ya están acostumbrados a compartir disco e impresoras, Linux también permite hacer esto y en mayor escala usando sus servicios o los de SAMBA para emular una conocida red privativa. Evaluar el usar una solución GroupWare para compartir recursos de disco podría ser muy beneficiosa, especialmente para asegurar las copias de seguridad.

·       Seleccionar una distribución no debe ser un dolor de cabeza pero si es importante. No es necesario reinventar la rueda (hacer tu propia distribución).Básicamente tenemos 2 tipos de distribuciones sobre las cuales elegir y tienen que ver mucho con el sistema de paqueteria que usan: Las basadas en RPM (Fedora, OpenSuse, Mandriva) las basadas en DEB (Ubuntu y Debian).Todas las distribuciones ofrecen lo mismo, para seleccionar que desktop usar haz un focus group con tus usuarios, hay 2 opciones viables Gnome y Kde, las oras opciones para hardware de poca potencia no son user-friendly.

·       El soporte de server siempre esta asegurado por el área informática, pero el soporte de usuarios en instituciones grandes debe ser bien organizado o la migración fallará.

·       Si es imposible tener un help desk especifico para problemas de usuarios entonces se debe entrenar 1 o 2 usuarios a un nivel de profundidad mas alto para que sean el primer soporte del área. Es posible contratar soporte externo para los usuarios, pero podría ser mas caro que el help desk interno, hay que evaluar económicamente cual es más rentable.

·       Casi todo aplicativo privativo tiene su contrapartida libre. Existen muchas guías sobre equivalencias de software en la red, ONGEI provee una mas o menos fiable.

·       No toda contrapartida libre ofrece el 100% de funcionalidades de su par privativo, en algunos casos los supera y en otros casos es menor, pero hay que evaluar con el usuario si esas funcionalidades no ofrecidas por la alternativa libre van a ser usadas en extenso, generalmente la respuesta es NUNCA LA USO.

Según los autores Fernando da Rosa y Federico Heinz. en su libro “Guía Práctica sobre Software Libre. Su selección y aplicación local en América Latina y el Caribe”.   se proponen dos formas de migrar al software libre: uno es el paso a paso y el otro es de una sola vez. A continuación se describen ambos:

Paso a paso: Comenzar a usar software libre en el sistema operativo privativo que estamos utilizando, Se puede comenzar sustituyendo aplicaciones de software privativo que utilizamos por sus contrapartidas en software libre. Una de las principales ventajas de esta forma de migración es que se pueden ir pasando los formatos cerrados a formatos abiertos de forma progresiva y sin cambiar el entorno operativo. Una vez que los usuarios se han familiarizados con las aplicaciones libres de uso cotidiano, se puede comenzar la migración del sistema operativo. La meta de este cambio gradual es terminar siendo 100% software libre.

De una sola vez: sustituyendo de entrada el sistema operativo y todas las aplicaciones por software libre. Esta es la opción más rápida, pero la más riesgosa, necesita de personal capacitado muy convencido del cambio y una mayor planificación

Existen diferentes tipos de migración. Se debe decidir cual conviene más.

Migración de los servicios (servidores): Para cada servicio que se ejecuta en el servidor debe existir una aplicación que se alimente de él en la parte del cliente. Por lo tanto, al realizar la migración de los servicios se comprueba si está disponible la correspondiente aplicación cliente.

Migración parcial: En caso que los servidores necesiten ofrecer servicios que únicamente dispongan de software propietario, se puede realizar una migración parcial. Para realizar esta tarea, se puede migrar el servidor a software libre, reemplazando todos los posibles servicios que tengan una alternativa basada en software libre. Para aquellos que no exista una alternativa viable, o que no se deseen cambiar, se puede realizar una migración parcial por virtualizacion. De esta manera, se corre otro sistema operativo encima del servidor con software libre, sobre el que se instalan únicamente los servicios que no se deseen/puedan migrar.

Migración de los usuarios (clientes): En este tipo de migración son únicamente las máquinas clientes las que migran su software. Puede realizarse una migración previa de los clientes y luego la de los servicios, y viceversa.

Migración de las aplicaciones: Puede darse el caso de que existan aplicaciones no migrables u otros factores que no permiten una migración total. De esta manera se escogen las aplicaciones que tienen una clara alternativa en software libre y se migran.

Migración de datos: Todas las aplicaciones, tanto las que se ejecutan en servidores y localmente, necesitan datos para trabajar. Por lo tanto se debe tener en cuenta la migración de datos a la nueva plataforma, incluyendo datos de ofimática, correos electrónicos, agendas, los datos de las aplicaciones propietarias y las base de datos.

La clave del éxito de un proyecto de migración, esta íntimamente relacionada a los siguientes aspectos: Definir un Objetivo claro y especifico, Contar con una planificación detalla, Poseer un grupo especializado y comprometido, Poseer el apoyo de algún  sponsor importante e influyente, Realizar correcciones a tiempo, Soporte continuo y Entrenar a los usuarios.

Fuente:

http://www.somoslibres.org/html.php?op=equivalencias.html

http://www.softwarelibre.gob.ve/documentos/Documento_Migracion.pdf

http://www.ceslcam.com/documentos/Taller_de_Migracion.pdf

http://hitecnews.wordpress.com/2011/04/11/caso-de-exito-en-realidad-de-fracaso/

http://softwarelibre.eventos.usb.ve/files/presentaciones/Presentacion_USB.pdf

Software Libre en VENEZUELA

La actividad de hoy demuestra que el Estado venezolano, declara y ejecuta acciones enfocadas en el Socialismo. Desde el 2004, cuando se publicó en Gaceta Oficial el Decreto 3.390 para promover el Software Libre en la Administración Pública Nacional surgió un gran debate sobre el conocimiento libre para alcanzar la independencia tecnológica. La meta distribución Canaima GNU/Linux apuesta a ese conocimiento libre, concretado en un sistema operativo hecho por venezolanos, para venezolanos y el mundo entero”, señaló Manuel Fernández, viceministro del Poder Popular para Ciencia, Tecnología e Industrias Intermedias.

Venezuela enfrenta el desafío de diseñar un Plan de Tecnologías de Información y Comunicación (PlanTIC) que incorpore en sus Lineamientos, Políticas y Estrategias, el conjunto de elementos que faciliten el despliegue de una Plataforma Nacional de Tecnologías de Información (PNTI), que democratice el acceso a la información y el conocimiento, con el apoyo de las tecnologías de comunicación y las posibilidades que brinda la Internet. En este orden de ideas, el Plan Nacional de Tecnologías de Información y Comunicación (PlanTIC) comparte la declaración de la Organización de la Naciones Unidas que sostiene la visión de una sociedad “dotada de habilidad, capacidad y pericia para generar y captar nuevos conocimientos y tener acceso a la información, a los datos y a los conocimientos, absorberlos y utilizarlos eficazmente con el apoyo de las TIC

Según los fundadores y representantes de la "Free Software Foundation", la máxima organización de Software Libre a nivel mundial, entre ellos Richard Stallman, cuando hicieron acto de presencia en Caracas, en el 2009,  resaltaron los adelantos del país en materia de Software Libre, hicieron recomendaciones y críticas constructivas para mejorar, en particular con Canaima GNU/Linux. “Venezuela presenta un liderazgo en la adopción del Software Libre en América Latina, aseguró el representante de la FSF-Brasil, Alexandre Oliva. Finalmente, fueron reconocidos los esfuerzos que venezolanos de la Comunidad de Software Libre y del gobierno de Venezuela han hecho en los últimos años para la adopción y divulgación de los programas y aplicaciones libres en el país. 

En ese evento, se reconocen los avances de Venezuela en la adopción de Software Libre, país que desde hace varios años tiene casi mil salas de computación o CBIT (Centros Bolivarianos de Informática y Telemática) instalados en las escuelas y liceos bolivarianos, donde se instruye a las y los niños de sectores populares usando exclusivamente Software Libre. Además, cientos de infocentros (centros de navegación provistos por el Estado para su uso gratuito por la población) usan software libre.

Son varios los ministerios y entes públicos, los cuales han ido migrando a Software Libre desde 2004, después del  Decreto Presidencial 3390 que exige que los entes del Ejecutivo Central usen programas y aplicaciones libres y estándares abiertos. Esta decisión, se ha ido cumpliendo paulatinamente, aunque con mucha resistencia por parte de funcionarios de entes públicos.  Se ha llevado a cabo el desarrollo de planes de formación de Software Libre para el personal técnico encargado de toda la infraestructura tecnológica, personal de soporte técnico y los usuarios finales de los sistemas.

La Comunidad de Software Libre (CSL) de la República Bolivariana de Venezuela continúa moviendo su agenda realizando ferias de instalación de Software Libre a nivel Nacional, también impartiendo talleres sobre la filosofía del Software Libre,  dando apoyo a los CeBIT (Fundabit), y se dictan Foros sobre la filosofía de software libre.

Los motivos que impulsan al uso y desarrollo del SL en nuestro país son los siguientes:

Razones económicas: Ahorros importantes al liberarse del pago de licencias y especialmente por la replicación casi gratuita de aplicaciones comunes a toda la administración pública. El muy bajo costo del software permitirá la ejecución de los programas

Independencia tecnológica: El Estado deja de depender de terceros (a menudo transnacionales) para el diseño, desarrollo y mantenimiento de sus sistemas de información, retomando el control total de sus procesos, en particular de los procesos críticos y de alta importancia estratégica para el país.

Control de la información: El acceso al código fuente, la libertad de inspeccionar el funcionamiento del software, la libertad de decidir la manera en que almacenan los datos y la posibilidad de modificar cualquiera de estos aspectos queda en manos del Estado, lo cual le permite el control total de la información y por consiguiente el ejercicio de la Soberanía Nacional.

Confiabilidad y estabilidad: El software libre realizado por comunidades está sometido a la inspección de un importante número de personas, este número de verificadores es mucho mayor que el del software propietario. Estas personas identifican los problemas, los resuelven, y comparten las soluciones con los demás. Por tal razón los programas libres de las comunidades gozan de gran confiabilidad y estabilidad.

Seguridad: La información que el Estado maneja generalmente es importante y/o confidencial, puede ser muy peligroso que esta información caiga en manos incorrectas. Por esta razón es imprescindible que el Estado pueda verificar que su software no tenga puertas de entrada traseras, voluntarias o accidentales, y que pueda cerrarlas en caso de encontrarlas; tal control sólo es posible con el software libre.

Desarrollo País: Se genera Transferencia Tecnológica hacia los actores nacionales productores de software, acelerando el Desarrollo Endógeno y reforzando la Soberanía Nacional.

Fuentes:

htp://www.radiomundial.com.ve/yvke/noticia.php?29160

http://www.softwarelibre.cl/drupal//?q=node/808

http://softwarelibre.gov.ve

http://www.softwarelibre.gob.ve/index.php?option=com_content&task=view&id

Aspectos Legales y Las Licencias en SL

Se puede definir como una licencia, una autorización formal con carácter contraactual que un autor de un software da a un interesado para ejercer "actos de explotación legales"

En el Software Libre, los grupos de licencias más comunes son:

Licencias GPL: en esta categoría una de las licencias más usada es la GNU GPL (Licencia Pública General de GNU), la cual posibilita la modificación y redistribución del software, pero únicamente bajo esa licencia.

Licencias AGPL: AGPL (Licencia Pública General de Affero). Es una licencia del tipo copyleft derivada de la GNU GPL diseñada para asegurar la cooperación con la comunidad en el caso de que el software corra en servidores de red.

Licencias BSD: el autor, bajo tales licencias, mantiene la protección de copyright, únicamente para la renuncia de garantía y para requerir la adecuada atribución de la autoría en trabajos derivados, pero permite la libre redistribución y modificación, incluso si dichos trabajos tienen propietario.

Tenemos que definir 2 términos utilizados en los párrafos anteriores:

Copyleft:     se define como una práctica al ejercer el derecho de autor que consiste en permitir la libre distribución de copias y versiones modificadas de una obra u otro trabajo, exigiendo que los mismos derechos sean preservados en las versiones modificada.  El copyleft es un término atribuido a Richard Stallman: Padre del proyecto GNU. Dicho término nace como una alternativa a las restricciones que imponen las normas planteadas en los derechos de autor "CopyRight", a la hora de hacer, modificar y distribuir copias de una obra determinada.  Con el copyleft se pretende garantizar una mayor libertad para que cada receptor de una copia, o una versión derivada de un trabajo, pueda, a su vez, usar, modificar y redistribuir tanto el propio trabajo como las versiones derivadas del mismo.

Copyright: se define como el derecho que tiene un autor, spbre todas y cada una de sus obras y que le permite decidir en qué condiciones han de ser éstas reproducidas o distribuidas.

Los derechos de autor consisten en un conjunto de facultades morales y patrimoniales que corresponden en forma exclusiva al autor de una obra, o a quien corresponda la titularidad de estos derechos por haberle sido transmitidos por el autor o por disposición legal, y conforme los cuales aquel puede beneficiarse de la utilización o comercialización de su obra, ya sea directamente o autorizando a terceros la realización de ciertos actos.

Existen dos tipos de derechos de autor, los morales y los patrimoniales o de explotación. Los derechos morales corresponden al autor de la obra y son irrenunciables e inalienables, por lo que no se pueden ceder ni renunciar a ellos.  Los derechos patrimoniales o de explotación facultan al autor a decidir sobre el uso de su obra, que no podrá llevarse a cabo sin su autorización, salvo en determinados casos.

En Venezuela existe una institución llamada Servicio Autónomo de la Propiedad Intelectual (SAPI) que es la encargada de velar por el derecho de autor en el país, es un organismo, adscrito al Ministerio del Poder Popular para el Comercio, que tiene la misión de ejercer eficientemente la rectoría del Estado venezolano, en materia de Derecho de Autor, marcas y patentes.

Entre las obras susceptibles a registro por Derecho de Autor que pueden ser avaladas por dicho organismo destaca los Programas de Computación y Bases de datos

Existe una variedad bastante grande de licencias libres y por razones prácticas la mayoría de los proyectos utilizan un pequeño conjunto. Por un lado muchos proyectos no quieren o no pueden dedicar recursos a diseñar una licencia propia. La mayoría de los usuarios prefieren referirse a una licencia ampliamente conocida que leerse y analizar licencias nuevas, complejas y completas. 

Las licencias se pueden dividir en dos grandes familias:

Licencias Permisivas: Está compuesta por las licencias que no imponen condiciones especiales en la segunda redistribución esto es, que sólo especifican que el software se puede redistribuir o modificar, pero no imponen condiciones especiales para éstos casos, esto conlleva por ejemplo, que alguien que reciba el programa pueda después redistribuirlo como software propietario.

Licencias robustas o licencias copyleft: que al estilo de la GNU GPL, imponen condiciones en caso de que se quiera redistribuir el software, condiciones que van en la línea de forzar a que se sigan cumpliendo las condiciones de la licencia después de la primera redistribución.

Las licencias libres más conocidas son:

GNU GPL (General Public Licence): GNU GPL es la licencia oficial del Proyecto GNU la más usada en el universo del software libre.

GNU LGPL (Lesser General Public Licence): GNU LGPL es la licencia Menor (Lesser) de la GPL. Antes era conocida como la licencia para Bibliotecas (Libraries) de las GPL, el nombre fue cambiado hace un tiempo para evitar su uso excesivo.

Licencia BSD: Esta licencia muy conocida por su posición “aun más libre” que la GPL es siempre un punto de discusión cuando se habla de licencias de Software Libre. Técnicamente una licencia del tipo BSD no tiene Copyleft, por lo que es posible hacer versiones modificadas no libres. Esto se ha dado mucho en la práctica, por ejemplo, Microsoft uso código de BSD en el sistema de red de Windows y muchos componentes de FreeBSD han sido usados en MacOS X. Hoy en día muchos proyectos grandes usan licencias del tipo BSD o inspiradas en su filosofía. Por ejemplo NetBSD usa una licencia BSD original.

Licencia X11: Es una licencia de software libre simple y permisiva sin Copyleft pero compatible con la GNU GPL. XFree86 usa la misma licencia. A veces se le llama la licencia del “ MIT“, pero ese término es engañoso puesto que el MIT ha utilizado muchas licencias para su software.

Licencia Pública de Mozilla (MPL): La licencia de la Fundación Mozilla cumple completamente con la definición de software de código abierto de la Open Source Initiative (OSI) y con las cuatro libertades del software libre enunciadas por la Free Software Foundation (FSF).

Licencia CDDL (Common Development and Distribution License): La CDDL (Desarrollo Común y Licencia de Distribución, en español) es una licencia Open Source (OSI) y Free software, producida por Sun Microsystems, basada en la Mozilla Public License o MPL, versión 1.1.

Licencia de la Fundación Apache: Existen tres versiones de la licencia Apache (1.0, 1.1. y 2.0) siendo la 2.0 la más empleada. Las dos primeras versiones carecen de Copyleft. La última versión es considerada una licencia de Software Libre.

Licencias libres para documentación: Como dije antes, no solo es importante liberar el software y su código fuente, también la documentación lo es. Ésta puede consistir en manuales, documentación de código y todo lo que el desarrollador considere importante para usar/modificar su programa.

GNU FDL (Free Documentation License): La licencia GNU FDL es la más extendida, básicamente su aplicación determina que la obra en cuestión pueda copiarse, modificarse y redistribuirse.

La Licencia de Documentación de FreeBSD: Es una licencia de documentación libre simple y permisiva sin Copyleft pero compatible con la GNU FDL. Creative Commons Atribución-CompartirDerivadasIgual.

Dentro de los Aspectos Legales, existe la Propiedad Industrial e Intelectual, que es la denominación por la que se conoce a diferentes figuras jurídicas que intentan resolver el problema de cómo proteger los bienes inmateriales (como el software) donde el concepto de posesión de los bienes materiales es inexistente. Esta protección, pasa por el reconocimiento de unos derechos exclusivos al autor o inventor de un bien intangible que permiten al titular de los mismos, poner límites al acceso o el disfrute de los demás sobre el objeto de su propiedad.

La mayoría de países cuentan con legislación nacional sobre propiedad intelectual e industrial, lo que propicia que tradicionalmente varíe de un país a otro, y sobre todo de una filosofía jurídica a otra. Por ejemplo, en la propiedad intelectual existen dos sistemas, los derechos de autor y el sistema del copyright. Sin embargo, en los últimos años ha existido una tendencia mundial a la armonización de las leyes nacionales a través de tratados internacionales. La propiedad intelectual e industrial se ordena tradicionalmente en dos grandes apartados: Propiedad intelectual, que se utiliza con un carácter sinónimo a derechos de autor y copyright (sobre obras literarias, artísticas y científicas); y  Propiedad industrial: patentes, marcas, secretos industriales, entre otros.

Fuente(s):

http://www.maestrosdelweb.com/editorial/licencias-libres-de-software-ii/

http://gbtcr.chileforge.cl/info_web/node1.html

http://www.maestrosdelweb.com/editorial/licencias-libres-de-software-i/

http://www.opensource.org/

http://www.gnu.org/

http://www.sourceforge.net/

http://www.principiolegal.com/licencias.php

http://es.wikipedia.org/wiki/Anexo:Comparaci%C3%B3n_de_licencias_de_software_libre

www.cnti.gob.ve

Bain Malcolm, Rodríguez Manuel, Ribas Manuel, Sanjuán Judit. Aspectos legales y de explotación del software libre. Parte I y II. Fundación  de la Universidad Oberta de Cataluña. Eureca Media SL. Barcelona. 2004

INGENIERIA DEL SL

Se puede definir a la Ingeniería del Software (IS) como una disciplina que ofrece métodos, metodologías, técnicas y herramientas para el desarrollo y mantenimiento de sistemas y aplicaciones de software complejas y de calidad.  La IS ha evolucionado históricamente en los siguientes pasos:

Primera Fase (1945-1955):

• Programar no es una tarea diferenciada del diseño de una máquina

• Uso de lenguaje máquina y ensamblador

• El desarrollador desempeña el rol de usuario

Segunda Fase (1955-1965)

• Aparecen multitud de lenguajes, por ejemplo: Cobol, PL/I, Simula 67

• Era posible hacer casi todo

• Programación orienta da a función

Tercera Fase (1965-1970)

• Desarrollo interminable de grandes programas

• Ineficiencia, errores, coste impredecible

• Nada es posible

Cuarta Fase. (1970-1980)

• Fundamentos de programación

• Verificación de programas

• Metodologías de diseño

• Programación orientada a módulos

• El desarrollador ya no cumple el rol de usuario

• Actividad de grupo

• Metodología en cascada

Quinta Fase. El diseño es el problema (1980-?)

• Entornos de programación

• Especificación formal

• Programación automática

• El usuario se incorpora en el proceso de desarrollo

• Inicio de aplicaciones basadas en Internet

• Relevancia de las interfaces de usuario

Esta disciplina surge a finales de los años 60, en el medio de la llamada "Crisis del Software" donde los proyectos de desarrollo eran inacabables, existía una enorme ineficiencia, los costos eran impredecibles y generalmente, aquellos que llegaban al final, (fuera de los tiempos estimados) ofrecían soluciones que ya los usuarios no necesitaban, por no mencionar lo difícil que resultaba el poder darles mantenimiento. Entonces, se decidió seguir el ejemplo de la "Ingeniería Civil", la cual ya tenia cientos de años progresando exitosamente, puesto que en programación se aplica el mismo principio que en la construcción de un edificio: poner simplemente ladrillos y cemento (echar código) no es suficiente. Su elaboración consta de diversos pasos antes de comenzar con la fase de construcción, tales como el diseño arquitectónico, la albañilería, la fontanería, el diseño eléctrico, y durante este período se calculan los presupuestos y los plazos.

La ingeniería de software requiere la gestión de proyectos para que se pueda desarrollar una aplicación en el plazo previsto y con el presupuesto establecido que sea satisfactoria para el cliente (el concepto de calidad). A partir de ese entonces, surgirían en las décadas siguientes, mucha cantidad de modelos de desarrollo, empezando por el tradicional Cascada, luego incorporando mejoras con el modelo espiral, y eventualmente se concebirían metodologías incrementales pesadas como la bien conocida Proceso Unificado o ágiles como XP.

Sin embargo independientemente de su naturaleza, todas siguen en mayor o menor medida los siguientes pasos o fases:

·           Requerimientos del software: la obtención, análisis, especificación y validación de los requerimientos para el software.

·           Diseño de software: diseño del software, generalmente llevado a cabo con herramientas CASE y el uso de lenguajes de diseño como el UML.

·           Desarrollo/implementación de software: es la construcción del software empleando lenguajes de programación.

·           Testeo/prueba del software.

·           Mantenimiento del software: solución de los problemas del software ya desarrollado

La ingeniería del software, en comparación con otras ramas de la ingeniería aún se encuentra muy joven, en los tiempos actuales aún se está buscando una forma clara de definirla o trabajarla y la búsqueda de estándares que lleven a un mejor perfeccionamiento en el desarrollo del software. De ahí las continuas interrogantes de considerarla ingeniería o no. Algunos autores consideran que sí, que aún se está en la etapa de establecimiento de bases, otros por el contrario no la califican como tal por falta de técnicas y conocimientos generales que se apliquen en el desarrollo del software.

Uno de los problemas actuales que enfrenta la ingeniería del software es el problema de la estimación. Aunque existen muchas teorías y técnicas al respecto, en la práctica ha resultado terriblemente difícil hacer buenas estimaciones de los proyectos de software.

Una de las grandes desventajas de las metodologías de desarrollo tradicionales o pesadas es precisamente la facilidad con la que el tiempo de desarrollo del proyecto se expande. Hasta cierto punto este problema se ha mejorado con las metodologías ágiles ya que estas se “deshacen” un poco de la formalidad y permiten ir directamente a la acción. Sin embargo, no resuelven el problema de la estimación, solo hacen más expedito el proceso de desarrollo. En ese sentido, vale la pena reflexionar y pensar que, del mismo modo en el que las metodologías de desarrollo han evolucionado a lo largo de los años (de pesadas a ágiles), las técnicas y herramientas para la estimación de proyectos de software también deben evolucionar.

En respuesta al problema de la estimación un grupo de personas han desarrollado el Evidence-Based Scheduling (Planificación Basada en la Evidencia). Este tipo de planificación plantea que, en lugar de hacer estimaciones iniciales y al final (cuando las estimaciones no se cumplen) preguntar ¿que paso?, se pueden usar los datos históricos de cada desarrollador para hacer simulaciones (usando el método de Monte Carlo) que permitan obtener estimaciones más precisas. De esta forma el gerente del proyecto podrá, por ejemplo, consultar la probabilidad de que el proyecto esté listo para la fecha planteada y tomar las decisiones que le permitan cumplir con este objetivo.  El Evidence-Based Scheduling no es ampliamente usado, pero el planteamiento central es lo que llama la atención: usar métodos estadísticos para hacer estimaciones más cercanas a la realidad.

Fuentes:

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software

http://es.kioskea.net/contents/genie-logiciel/genie-logiciel.php3

http://www.alegsa.com.ar/Dic/ingenieria%20del%20software.php

http://es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3

http://www.cepeu.edu.py/LIBROS_ELECTRONICOS_3/lpcu097%20-%2001.pdf

http://en.wikipedia.org/wiki/Software_engineering

http://www.acis.org.co/fileadmin/Revista_102/columnista.pdf

http://www.ati.es/novatica/2000/145/luifer-145.pdf

http://www.fogcreek.com/fogbugz/evidence-based-scheduling/

http://www.joelonsoftware.com/items/2007/10/26.html

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_del_software

Actividades en la IS - Modelos de desarrollo de software. Prof. Pedro Bonillo

http://www.um.es/docencia/barzana/IAGP/Iagp1.html

UML

UML presenta un conjunto de notaciones y diagramas estándarizados para modelar sistemas, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Anteriormente se manejaban diversas notaciones y métodos para el modelado, ahora se cuenta con una única notación. Este estándar ofrece nueve diagramas en los cuales modelar sistemas.

•  Diagramas de Casos de Uso para modelar los procesos ’business’.

•   Diagramas de Secuencia para modelar el paso de mensajes entre objetos.

•   Diagramas de Colaboración para modelar interacciones entre objetos.

•   Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.

•   Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.

•   Diagramas de Clases para modelar la estructura estática de las clases en el sistema.

•   Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.

•   Diagramas de Componentes para modelar componentes.

•   Diagramas de Implementación para modelar la distribución del sistema.

UML es una de las propuestas más exitosas de una notación estándar para describir los diferentes elementos que componen el software. La utilización de una notación estándar para describir las aplicaciones es de vital importancia en la ingeniería de software, ya que además de dibujar una suerte de "mapa" de las aplicaciones, facilita la colaboración en los equipos de desarrollo, ya que en teoría, dada una buena documentación UML, cualquier desarrollador podría entender rápidamente las interacciones entre los componentes de un sistema, los elementos que lo componen, los flujos de datos, etc.

El UML se puede utilizar para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir, es el lenguaje en el cual está descrito el modelo, es un lenguaje para especificar y no para describir métodos o procesos.  En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en una gran variedad de formas para dar soporte a una metodología de desarrollo de software, pero no especifica en sí mismo qué metodología o proceso usar.

Los principales beneficios de UML son:

• Mejores tiempos totales de desarrollo (de 50 % o más).
• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
• Establecer conceptos y artefactos ejecutables.
• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
• Mejor soporte a la planeación y al control de proyectos.
• Alta reutilización y minimización de costos.
• Produce un aumento en la calidad del desarrollo.
• Permite especificar la estructura y el comportamiento del sistema y comunicarlo a todos los integrantes del proyecto.
• Brinda la posibilidad de obtener un "plano" del sistema.
• Permite dimensionar mejor los riesgos de un proyecto tener un mejor rendimiento antes de construir el sistema.
• Facilita la documentación de las decisiones de la arquitectura del proyecto.
• Ofrece un mejor soporte a la planificación y control del proyecto.
• Ofrece mayor rigurosidad en la especificación.
• Permite realizar una verificación y validación del modelo realizado.
• Se pueden automatizar determinados procesos y permite generar código a partir de los modelos y viceversa.

Motivado a que los diagramas preexistentes no logran adaptarse perfectamente a las particularidades de cada aplicación, parte de la especificación del UML se dedica a definir mecanismos de extensión con miras a incrementar el campo de aplicación del lenguaje.

Entre estos mecanismos, tenemos los llamados Estereotipos los cuales añaden pequeñas etiquetas a los elementos o relaciones de un diagrama otorgándoles un nuevo significado. Es decir, que por medio de los estereotipos vamos a poder aplicar las herramientas UML a nuevas áreas de modelado, presuponiendo que estas áreas trabajan con los conceptos básicos del lenguaje y requieren solo de expresar las ideas propias del sector.

Con los estereotipos, se reducen las limitantes atadas a lo estricto que pudieran resultar los diagramas que conocemos seguidos al pie de la letra con las notaciones formales conocidas. Siendo UML un lenguaje visual, como parte de la definición de un estereotipo podemos incluir una imagen o icono de manera de hacer más atractivos y legibles a nuestros diagramas. De hecho, cuando vemos un diagrama UML con imágenes ocupando el lugar de elementos, lo que estamos viendo es en realidad, elementos estereotipados.

Aunque para Windows disponemos de muchas herramientas que nos facilitarían el trabajo al momento de modelar UML, y al menos se que se puede utilizar StarUML mediante el emulador Wine, para GNU/Linux, se puede encontrar que las mas completas son: ArgoUML, BOUML, Dia y UMBRELLO.

 ArgoUML: Es una aplicación de diagramado de UML escrita en Java y publicada bajo la Licencia BSD. Dado que es una aplicación Java, está disponible en cualquier plataforma soportada por Java. Incluye el apoyo a todos los estándares de diagramas UML 1.4.

BOUML: Es una herramienta que permite modelar UML 2 y a su vez especificar y generar código en C++, Java, IDL, PHP y Python. Es multiplataforma pues corre en Unix / Linux / Solaris, MacOS X (Power PC e Intel) y Windows. De acuerdo a la información presentada en su página principal, es muy rápido y no requiere mucha memoria para manejar varios miles de clases. Además permite añadir aplicaciones externas escritas en C++ o Java, siendo una de estas extensiones predefinidas la generación de código y la ingeniería inversa.

Dia: Esta basado en GTK+ bajo la licencia GPL. Se inspira en el programa comercial de Windows ‘Visio’, y puede ser usado para dibujar muchos tipos diferentes de diagramas. Dispone de una serie de extensiones para ayudar en la elaboración de diagramas entidad-interrelación, UML, flujo de datos, diagramas de red, entre otros etc.

UMBRELLO: De acuerdo a muchos artículos, es una de las herramientas más intuitivas para aquellos que están pocos acostumbrados a trabajar con UML. Guarda la estética común a todos los programas desarrollados para y por KDE, aunque también puede funcionar en entornos GNOME. Soporta la generación de código a partir del modelo de elementos y los diagramas para un gran número de lenguajes (Java, PHP, C++, XML, etc.).

También encontramos que UML presenta una serie de debilidades:

• UML no te va a decir cómo pasar del análisis al diseño y de este al código. No son una serie de pasos que te llevan a producir código a partir de unas especificaciones.
• UML al no ser un método de desarrollo es independiente del ciclo de desarrollo que vayas a seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo ciclo en espiral o incluso en los métodos ágiles de desarrollo.
• Diversos desarrolladores también dan nota de que UML es algo impreciso dentro de su notación, por ejemplo, al hacer referencias a un diagrama con servidores, no se sabe si los servidores simbolizados se encuentran operativos, restringidos, pasivos…etc. Por eso se le califica de un poco inexacto.
• Otro problema de UML es que no se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que un objeto es persistente o remoto.
• UML siempre ha sido muy criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva

Fuente:

http://www.docirs.cl/uml.htm

http://synergix.wordpress.com/2008/07/20/estereotipos-en-uml/

ftp://jano.unicauca.edu.co/cursos/EnfasisIV/uml/ModeladoInternet.pdf

http://uml.sourceforge.net/

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

http://argouml.tigris.org/

http://bouml.free.fr/

http://live.gnome.org/Dia

http://umbrello.softbull.com/

http://www.uml.org

http://foros.clubdesarrolladores.com/index.php/topic,418.0.html

http://alvearjofre.galeon.com/

http://www.ingenieriasw.com/uml

http://www.programacion.com/articulo/introduccion_a_uml_181

http://profesores.fi-b.unam.mx/carlos/aydoo/uml.html

http://www.cientec.com/analisis/ana-uml.html

http://goo.gl/QPt2B