¿Que es Open Source? Definición

Hablamos mucho de programas Open Source y Linux y a veces, hay algunas confusiones sobre que es, realmente un programa Open Source. Parte de la confusi󮬠quizás¬ venga de la traducció® ¬iteral de “Free Software” que en Inglés puede ser Software Gratis o Software Libre (algo totalmente diferente).

Y aunque no hay error conceptual al hablar de Software Libre, que mejor que ir a la fuente y traducir exactamente la definició® ¤e ¿Que es Open Source?

Update: Un ejemplo de lo estricta que es la definicion con la licencia de Apache 2.0

La Definició® „e Fuente Abierta (Versió® q.9)

Las secciones puestas en letra itᬩca aparecen como anotaciones a la definició® ¡bierta de la fuente (OSD) y no son una parte del OSD, sino una forma de entender que se busca con cada una de estas cláµsulas.

Introducció®f¬t;/b>
Fuente abierta no significa s󬡭ente el acceso al c󤩧o de fuente. Los t鲭inos de la distribuci󮠤el software de Fuente-Abierta deben conformarse con los criterios siguientes:

1. Redistribució® Œibre
La licencia no restringirá ¡ ninguna parte el vender o de dar gratuitamente el software como componente de una distribució® ¤el software agregada que contenga programas de diversas fuentes. La licencia no requerirá ¤erechos u otro honorario para tal venta.
Anᬩsis razonado: Obligando la licencia a requerir la redistribució® ¬ibre, eliminamos la tentació® ¤e evitar muchos aportes a largo plazo para hacer algunos d󬡲es a corto plazo por ventas. Si no hici鲡mos esto, habrí¡ presió® °ara que los coperadores deserten.

2. C󤩧o De Fuente
El programa debe incluir c󤩧o fuente, y debe permitir la distribució® en c󤩧o fuente como así ´ambié® en forma compilada. Cuando una cierta forma de un producto no se distribuya con c󤩧o de fuente, deben existir medios bien publicados para obtener el c󤩧o fuente por no más de un costo razonable de preproducci󮬠descargandolo ví¡ Internet sin cargo. El c󤩧o fuente debe ser la forma preferida en la cual un programador modificarí¡ el programa. El c󤩧o de fuente deliberadamente “obscurecido” no se permite. Las formas intermedias tales como la salida de un preprocesador o de un traductor no se permiten.
Anᬩsis razonado: Requerimos el acceso al c󤩧o fuente sin obscurantismo porque usted no puede desarrollar programas sin la modificació® ¤el mismo. Puesto que nuestro propós©´o es hacer la evolució® fᣩl, requerimos que la modificació® esté ¨echa fᣩl.

3. Trabajos Derivados
La licencia debe permitir modificaciones y trabajos derivados, y debe permitir que sean distribuidos bajo los mismos té²­inos que la licencia del software original.
Anᬩsis razonado: La mera capacidad de leer codigo fuente no es suficiente para apoyar la revisió® ¤e par (N.B.:se acuerdan del peer-review?) independiente y la selecció® evolutiva rá°©da. Para que la evoluci󮠲ᰩda suceda, la gente necesita poder experimentar con, y redistribuir, modificaciones.

4. Integridad del c󤩧o de fuente del autor
La licencia puede restringir c󤩧o fuente de ser distribuido en forma modificada solamente si la licencia permite la distribució® ¤el “patches” con el c󤩧o fuente con el fin de modificar el programa al momento de la construcció®® La licencia debe permitir explí£©tamente la distribució® ¤el software construido de c󤩧o fuente modificado. La licencia puede requerir que los trabajos derivados lleven un nombre diferente o un nò­e²o de versió® ¤iferente al del software original.
Anᬩsis razonado: Animar mejoras es una buena cosa, pero los usuarios tienen derecho a saber quié® es el responsable del software que 鬠está µtilizando. Los autores y los sostenes tienen derecho recí°²oco de saber en que les está® pidiendo soporte y a proteger sus reputaciones.

Por consiguiente, una licencia de Fuente-Abierta debe garantizar que esa fuente esté fᣩlmente disponible, pero puede requerir que esté ¤istribuida como fuentes base (“base source”)prís´inas más “patches”. De esta manera, los cambios “no-oficiales” se pueden poner disponibles pero ser fᣩlmente distinguibles de la fuente base (“base source”).

5. Ninguna discriminació® £ontra personas o grupos
La licencia no debe discriminar contra ninguna persona o grupo de personas.
Anᬩsis razonado: Para mḩmar los beneficios del proceso, la diversidad mḩma de personas y grupos deben ser elegibles para poder contribuir a las fuentes abiertas. Por lo tanto prohibimos cualquier licencia de la Fuente-Abierta impedir a cualquier persona o grupo formar parte del proceso.

Algunos países, incluyendo los Estados Unidos, tienen limitaciones de exportació® °ara ciertos tipos de software. Una licencia que cumple con OSD puede advertir a los concesionarios de las restricciones aplicables y recordarles que está® obligadas a obedecer la ley; sin embargo, puede no incorporar tales restricciones sí ­ismo.

6. Ninguna discriminació® £ontra Campos de Esfuerzo
La licencia no debe restringir cualquier persona de hacer uso el programa en un campo específ©co. Por ejemplo, no pueden restringir al programa ser utilizado en negocios, o ser utilizado para la investigació® §ené´©ca.
Anᬩsis razonado: La intenció® °rincipal de esta cláµsula es prohibir las trampas de licencias que evitan que la fuente abierta sea utilizada comercialmente. Quisi鲡mos que los usuarios comerciales se uniera a nuestra comunidad, no darles la sensació® ¤e estar excluidos de ella.

7. Distribució® ¤e la licencia
Los derechos unidas al programa deben aplicarse a todos a quié® el programa se redistribuye sin la necesidad de la ejecució® ¤e una licencia adicional por esas partes.
Anᬩsis razonado: Esta cláµsula es pensada para prohibir cerrar el software por medios indirectos tales como requerir un acuerdo de confidencialidad.

8. La licencia no debe ser específ©ca a un producto
Los derechos unidos al programa no deben depender del programa que es parte de una distribució® °articular del software. Si el programa se extrae de esa distribució® ¹ es utilizado o distribuido dentro de los té²­inos de la licencia del programa, todos aquellos a los cuales se redistribuye el programa tienen los mismos derechos que los que se concedan conjuntamente con la distribució® ¯riginal del software.
Anᬩsis razonado: Esta cláµsula excluye otra clase de las trampas de la licencia.

9. La Licencia No debe Restringir El Otro Software
La licencia no debe poner restricciones en el otro software que se distribuye junto con el software licenciado. Por ejemplo, la licencia no debe insistir que el resto de los programas distribuidos en el mismo medio deben ser software de Fuente-Abierta.
Anᬩsis razonado: Las distribuidores del software de Fuente-Abierta tienen el derecho de hacer sus propias decisiones sobre su propio software.

Sí¬ el GPL cumple con este requisito. El software unido a bibliotecas “GPLadas” hereda solamente el GPL si forma un solo trabajo, no el software con el cual simplemente se distribuyan.

* 10. La Licencia Debe Ser Tecnologicamente-Neutral
Ninguna disposició® ¤e la licencia se puede afirmar en una tecnologí¡ o estilo de interfaz individual.
Anᬩsis razonado: Esta disposició® está ¤irigida específ©camente a las licencias que requieren un gesto explí£©to de asentimiento para establecer un contrato entre el licenciador y el concesionario. Las provisiones que por mandato llamado “click-wrap” pueden estar en conflicto con mé´¯dos importantes de distribució® ¤e software tales como transferencia directa de ftp, antologí¡s en CD-ROM, y “mirroring”; y tales provisiones pueden tambié® obstaculizar la reutilizació® ¤el c󤩧o. Las licencias de conformidad deben permitir la posibilidad que (a) la redistribució® ¤el software ocurrirá sobre los canales de no-Web que no apoyan “click-wrap” de la transferencia directa, y que (b) el c󤩧o cubierto (o las porciones reutilizadas del c󤩧o cubierto) puede funcionar en un ambiente no-GUI que no soporte diᬯgos del popup.

ce Definition

Nota: La traducció® °uede ser mejorada, seguramente en algunos detalles de traducciones como “click-wrap” porque es medio dificil de consolidar en una o dos palabras como concepto, pero las contribuciones se aceptan sin problemas de Ego… al fin del dí¡ estamos hablando de fuente abierta, no? ;)

18 thoughts on “¿Que es Open Source? Definición”

  1. oaky, en realidad hay un debate sobre la licencia 2.0 de Apache porque el punto 5 se contradice con una parte de la tercera cláusula de la licencia de OSI en lo referido a los trabajos derivativos.

    Se dice que en la nueva versión de la Licencia Open Source se va a incluir esta modificacion de acuerdo a esto: http://tinyurl.com/2wd94

  2. ¿Eh? Estás haciéndote un lío. Ahí están hablando de que la nueva licencia de Apache no es compatible con la GPL, nada más, no de si es “libre” o “abierta” (cosa que nadie discute). La GPL es una licencia más, pero la más importante y la más usada, por eso es importante para otra licencia ser compatible con ella (si no lo es, código liberado bajo la GPL no puede ser combinado con código liberado bajo la otra licencia (y viceversa)). Por último, (a) la GPL *no* es la licencia OSI; (b) ¿qué es la licencia OSI? Es la primera vez que escucho eso.

  3. Oaky, cuando digo Licencia OSI, en realidad me estoy refiriendo a la Licencia Open Source “oficial”aprobada por la OSI (open source Initiative)… no es que invente algo por ahi ;)

    Creo que estamos diciendo lo mismo… porque la licencia version 2.0 de Apache no cumple estrictmente con las especificaciones/requisitos de la OSI para ser considerada una licencia Open Source total.

    Nadie discute que Apache es Open Source o que sea Libre/abierto en su filosofia; pero lamentablemente a nivel legal no es compatible con la licencia GPL por ese punto.

    Y al ser OSI lo que certifica que un producto sea Open Source, Apache con su licencia 2.0 no es considerado Open Source por la Open Source Initiative/Foundation.

  4. Seguís haciéndote lío.

    No hay “Licencia Open Source Oficial”. La OSI tiene una serie de requerimientos que tiene que cumplir una licencia para que ellos la consideren “open source” (lo que vos posteaste) y una lista de licencias[1] ‘certificadas’ por ellos. Esa ‘certificación’ sólo significa que la ‘certificaron’, nada más, no hace a una licencia más o menos “open source” (pero le permite al certificado decir que su programa es ‘Open Source(tm)’ y ‘OSI certified(tm)’ –ellos registraron los términos–). Probablemente certifiquen la nueva licencia de Apache cuando los de Apache decidan presentarla para su certificación.

    Ya te expliqué lo que es ser compatible con la GPL. La GPL es una licencia creada por la FSF[2], y no tiene nada que ver con la OSI (salvo que los de la OSI la ‘certificaron’ de prepo, como para darse legitimidad ;). Una licencia puede ser “libre” u “open source” y no por ello ser compatible con la GPL. Por ejemplo, acá[3] tenemos la nueva licencia de Apache y la licencia de PHP4.

    Che, y de onda, pero si no te interesa el tema y no te querés informar, mejor no escribir nada antes que mandar información errónea, ¿no?

    1. http://www.opensource.org/licenses/
    2. http://www.fsf.org/
    3. http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses

  5. oaky… puede ser que este equivocado, y de hecho gracias por iluminarme,… pero si no me interesara el tema o no me intersara informarme.. te borraria el comentario por pelotudo :)

  6. ahora con tiempo…

    Oaky, leiste bien mi update? dije claramente: “Update: Un ejemplo de lo estricta que es la definicion con la licencia de Apache 2.0”

    Sólo quise demostrar que la Licencia 2.0 de Apache es incompatible con GPL, de hecho es lo mismo que dice el tercer link que pones vos… lee bien “The Apache Software License, version 2.0: This is a free software license but it is incompatible with the GPL”

    Donde GPL significa “GNU Public Licence” o sea es una licencia.

    Por otro lado, te repito que el debate esta todavía sin resolución, a no ser que vos sepas algo que Slashdot no sabe… y que el trabajo que se están tomando en Apache Software Foundation sea al pedo.

    Y finalmente.. todo bien :)

  7. La licencia de Apache 2.0 (A) cumple con la definición.
    La licencia BSD (B) (por poner otro ejemplo) cumple con la definición.
    La GPL (G) cumple con la definición.

    A y B son compatibles entre sí.
    B y G son compatibles entre sí.
    A y G no. Nada más.

    Todo bien también, eh.

  8. hola quisiera mayor informacion de “open source” es urgente , desde sus inicios hasta la actualidad
    gravias a todos aquellos que me hagan caso

  9. Visiten http://www.gnu.org. Hay una sección en castellano.

    Mariano, una pregunta ¿porqué linkeaste a opensource y no a GNU? Aclaro que pregunto de curioso porque soy newbie en el tema, lo único que leí fue del sitio de GNU y por lo que entendí habrían diferencias ideológicas entre el Opensource y el FreeSoftware.

    Gracias.

    PS: ¿Y un RSS a los comments?

  10. (Corríjanme si me equivoco)

    EL Software Libre (Free Software) es un movimiento distinto del Código Abierto (Open Source).
    El primero es producto de la Free Sofwtware Foundation, que es anterior a la Open Source Initiative (representa al otro).

    La FSF es responsable de la GPL, una licencia que regla que el software publicado bajo la misma deberá:
    1. Brindar el código fuente.
    2. Permitir a los usuarios la modificación del software;
    3. y la redistribución del mismo;
    4. SIEMPRE bajo los términos de la GPL (lo que significa que la nueva versión deberá permitir todo esto).

    En cambio, la OSI engloba variadas licencias en las que el requisito fundamental es la accesibilidad al código fuente, pero admite que algunos derechos sean restringidos.
    Por eso también abarca a la GPL, junto con otras licencias que restrinjen algunos derechos que la GPL asegura.

    Básicamente el asunto es ideológico. La FSF habla de software libre, ‘libre como en libertad de expresión, no como en cerveza libre‘, mientras que la OSI únicamente del acceso al código.

    (Mas información: http://www.fsf.org/philosophy/free-software-for-freedom.es.html)

  11. jh.. si.. totalmente de acuerdo con eso, por ese motivo el problema que dio origen a la nota se habia originado en la licencia de Apache 2.0.. hace ya untiempo laaaargo

Leave a Reply

Your email address will not be published. Required fields are marked *