#8 No hay 2 personas para sentarse en el mismo asiento. Si todos los asientos han sido asignados, al intentar hacer el check in te sale un mensaje diciendo que vayas al mostrador de facturación.
#17 Creo que sí es importante comprender la diferencia entre los diversos conceptos.
Actualmente, hay varias empresas que están usando licencias no libres con diversos términos como "Source Available", "Server Side Public License", o "Common clauses" para hacer parecer que son "Una variante de open source". Los propios modelos de IA son un ejemplo ya que meta intentó que Llama fuese referido como "Open Source" a pesar de que su licencia fue clasificada como "no open source" por la OSI (y, también como "No libre" por la FSF).
Si se generaliza el usar el término "Software Open Source" como algo claramente diferente al "software libre" (refiriendose al software, no a las iniciativas, que sí son diferentes), eso hace más fácil que la gente se confunda y piense que esas licencias y ese software son "Open Source" aunque no sean "Software Libre".
#15 Sí, pero eso no quiere decir que la licencia MIT no sea software libre.
El hecho de que "Uno de los aspectos más importantes de la GPL es su naturaleza viral. Si usted utiliza y distribuye código GPL en su proyecto, éste también debe estar licenciado bajo la GPL." se llama "Copyleft", no "Software Libre". Es decir, la diferencia no es "Open Source" vs "Software Libre", si no "Licencia sin copyleft" vs "Licencia con copyleft"
La GPL es software libre porque permite usar para cualquier fin, estudiar el código, modificar el código y redistribuir las versiones modificadas. Además es copyleft porque requiere que las versiones modificadas sigan siendo software libre.
La licencia MIT es software libre porque permite usar para cualquier fin, estudiar el código, modificar el código y redistribuir las versiones modificadas. No es copyleft porque no requiere que las versiones modificadas sigan siendo software libre. La MIT está incluida en el listado de licencias libres reconocidas por la FSF: www.gnu.org/licenses/license-list.html (aunque la FSF le llama "expat license")
#11 Creo que estás confundiendo Open Source/Software libre con Software libre con copyleft / Software libre sin copyleft.
Los movimientos de Open Source y Software Libre usan términos y motivaciones diferentes pero los criterios que la FSF usa para establecer que una licencia es de Software Libre son muy similares a los criterios usados por la OSI para establecer que una licencia es Open Source. Aquí tienes la página donde la FSF clasifica como "Free and GPL compatible License": directory.fsf.org/wiki/License:Expat
Puede haber varios motivos por los que haya elegido la licencia MIT. Si por que usa una librería "Open Source" te refieres a que usa librerías que usan licencias sin copyleft, mientras esas librerías usen licencias compatibles con la GPL, no debería de ser un problema, por lo que dudo que sea el motivo.
#66 Lo que la FSF ha dicho no es "se ha redactado con tal fin", lo que ha dicho es "Al haber usado la AGPL como licencia para vuestros usuarios, habéis dado derecho a vuestros usuarios a ignorar las cláusulas que añadisteis, ya que si demandáis a alguien por incumplir las cláusulas extras que han añadido pueden decir: "Según el artículo 10 de los términos de uso establecidos por el demandante, tengo derecho a ignorar las cláusulas extra puestas por el demandante.".
No es que "no te leas lo segundo", es que al haber usado lo primero, te dan derecho a ignorar lo segundo. La empresa que tiene el copyright de OnlyOffice podría haber llevado a pleito si opinase que no es así, pero ha decidido no hacerlo, seguramente porque tras la revisión de sus abogados habrán visto que no tenían posibilidad, y en lugar de eso han preferido cambiar las cláusulas extra que se aplican a las nuevas versiones para no tener este problema.
Lo que ha pasado aquí es que una empresa quería anunciar su suite ofimática como "Suite ofimática libre", pero creía que se guardaba un as en la manga para poder pedir royalties a sus usuarios en un futuro, y resulta que la forma que ha elegido para hacerlo era incorrecta. Podrían haber creado su propia licencia, como hacen otros proyectos no libres que "quieren pasar por libres", pero, como comenta #64, eso habría dado mala prensa.
#63 A esas normas le han puesto el asterisco basándose en la propia AGPL. Es decir, las normas eran: "Según los artículos 7b de la AGPL tienes que incluir mi logo, y según el artículo 7e AGPL no te doy permiso a incluir mi logo". Lo que le han dicho los abogados de la FSF es: "El artículo 10 autoriza a los usuarios a eliminar restricciones adicionales según el artículo 7 si eso es necesario para ejercer los artículos 4 y 5".
La AGPL no es la legislación de ningún estado, lo que es en este caso es un acuerdo entre los titulares del copyright, y las personas que utilizan el software. Es decir, no es ningún estado el que haya permitido que el software se pueda copiar, si no los titulares del copyright (la empresa que desarrolla OnlyOffice). Al decirte: "Puedes usar mi software si cumples estas normas" (lo que ocurre es que las normas que ellos estaban estableciendo para usar el software autorizaban a eliminar las restricciones que ellos habían intentado poner)
#61 Pero es que no se considera nulo. Lo que han hecho es, de forma consciente o inconsciente, dar una autorización a redistribuir software cumpliendo unas normas. Mientras las personas cumplan esas normas, la autorización es válida. Eliminar las dos restricciones añadidas al amparo del artículo 7 de la AGPL cumple las normas si se hace según los artículo 4, 5 y 10.
Lo que no pueden hacer es: como no me gusta como estás usando las normas que hemos acordado la autorización que acordamos ya no es válida.
Lo pueden hacer de ahora en adelante (para la gente que se descargue el software de ahora en adelante), pero no lo pueden hacer con la gente que ya se ha descargado el software.
#56 Un juez tiene que dictaminarlo si las partes están en desacuerdo. La empresa que desarrolla OnlyOffice tras leer la explicación de los abogados de la FSF ha aceptado que es "unenforceable" y por tanto acepta que la explicación de la FSF es correcta. No se puede "volver a la fase de inicio" porque eso implicaría anular permisos de uso que ellos ya han dado a millones de usuarios.
Es decir, versión simplificada, ellos habían distribuido software afirmando: "1. Puedes usar, copiar y modificar el software. 2. Para hacer eso tienes que incluir mi logo. 3. No tienes permiso para incluir mi logo. 4. Puedes eliminar las cláusulas de este contrato que te impidan copiar y modificar el software" No pueden "Volver a la fase de inicio" porque sería romper el acuerdo con millones de usuarios que ya usan OnlyOffice. Los usuarios que aceptaron la AGPL para usar OnlyOffice no tienen la culpa de que el desarrollador pensaba que no se podía a efectos prácticos redistribuir su software sin su permiso.
#53 Supongo que si se hubiesen dado cuenta de que al usar la AGPL esas cláusulas podrían ser anuladas, habrían buscado otra forma de hacer eso, como cambiar la licencia.
#42 Lo que la FSF alegó es que al haber elegido la AGPL con dos restricciones adicionales, debido a una de las clásusulas de la AGPL, OnlyOffice estaba autorizando a todos los usuarios a eliminar dichas cláusulas. Es decir, la autoridad a los usuarios de no respetar esas cláusulas no la otorgó la FSF, si no que la había otorgado la empresa desarrolladora de OnlyOffice de manera involuntaria a los usuarios al usar la AGPL como licencia.
#44 Pero es que OnlyOffice ha aceptado que la FSF tenía razón en su interpretación de la AGPL y ha cambiado las cláusulas adicionales de la licencia. Esta noticia es de marzo, desde entonces, OnlyOffice ha cambiado la licencia, precisamente porque se dió cuenta de que lo que estaba escrito no era lo que ellos creían y al usar AGPL que hecho que sus las cláusulas adicionales fuesen "unenforceables"
#12 El problema era que, con la interpretación de licencia que intentaba forzar Onlyoffice, no prodría considerarse Onlyoffice como software libre.
OnlyOffice argumentaba que añadía dos restricciones a la AGPL:
1. Cualquier fork tendría que incluír el logotipo de OnlyOffice
2. El logotipo de OnlyOffice no podría ser incluído sin autorizaciṕn del propiertario del Trademark
Esto a efectos prácticos hacía imposible hacer un fork sin permiso de OnlyOffice, lo cual hacía que no pudiese ser considerado software libre si se entendía que la interpretación de la AGPL era la correcta. La FSF ha argumentado que, en este caso, los artículos 5 y 10 de la AGPL permiten a cualquier persona que tenga el software retirar de la licencia los "requerimientos adicionales", y eso es lo que ha hecho EuroOffice.
Esta noticia es de marzo, desde entonces OnlyOffice ha cambiado su postura ya que, recibió una clarificación por parte de los abogados de la FSF de que estaba interpretando unas cláusulas de la FSF de forma errónea.
Principalmente, OnlyOffice intentó usar dos cláusulas de la AGPL para: Exigir que cualquier versión modificada incluyese el logotipo de OnlyOffice, y dejar el logotipo del OnlyOffice fuera del alcance de la AGPL. Es decir, ellos decían: Puedes hacer versiones modificadas de OnlyOffice siempre que incluyan mi logotipo, pero si incluyes mi logotipo sin mi permiso me reservo el derecho a demandarte. (Lo cual, evidentemente hacía que el software no fuese libre).
Los abogados de la AGPL clarificaron que hay una cláusula (el artículo 10) que permite anular esos requisitos cuando se usan para limitar otros derechos (que es en lo que se valió EuroOffice), y, OnlyOffice aceptó que ese era el caso y cambió los requisitos adicionales de la licencia: github.com/ONLYOFFICE/DocumentServer/commit/a07795c4bd64f29552b9419ce1
#7 Bueno, la idea de subdividir el paquete completo tenia varias causas. Una de ellas era destacar que son componentes independientes (puedes usar okular aunque no uses Plasma, y si usas Plasma no tienes por qué usar okular como lector de documentos)
La segunda, y quizás más importante aunque no sea muy "visible", es que continuar lanzando todo junto "no era viable". Esto se vió especialmente con el caso de KDE 4.0. Había varios componentes (las librerías, algunas aplicaciones) que estaban preparados, pero desde luego Plasma aún no era estable. Sin embargo, el tener que lanzarlo "todo junto" (no se podía publicar kate 4.0 sin publicar también Plasma 4.0) hizo que se publicase una versión que, en conjunto, no estaba preparada, y eso dañó mucho a la marca.
Como ahora son productos independientes, cuando sale una nueva versión mayor, cada componente va publicando la versión adaptada a las nuevas versiones de las librerías cuando están listos sin sentir "presión" porque otros componentes no estén preparados.
#3#4 La noticia no menciona el ambito geográfico de las personas sobre las que se ha hecho el estudio, pero teniendo en cuenta que ha colaborado la Universidad de Nueva York, me tiene pinta de que no se refiere a los jóvenes de España
#8
wine y ReactOS implementan unicamente el API de Windows, no el procesador x86/x86_64.
Eso quiere decir que puedes ejecutar aplicaciones Windows en un procesador que pudiese ejecutar dichas aplicaciones, no en una arquitectura hardware diferente. Existen proyectos que intentan emular x86 y llamadas a windows de forma conjunta, por ejemplo este: github.com/AndreRH/hangover pero supongo que están lejos del nivel de compatibilidad de wine.
#2#25#5 Entiendo que aunque sigan sacando distros compatibles, veo poco probable que estas distros incorporen versiones personalizadas del kernel (es decir, veo poco probable que alguien mantenga versiones posteriores del kernel para esas arquitecturas)
Si se lee el email en la lista de correo en donde comentan esto, parece que es porque los desarrolladores del kernel no usan ese hardware y tienen problemas para emular esos procesadores específicos (un sistema de virtualizacion intentará emular un x86 con el máximo número de instrucciones, hay poca demanda de emuladores de 486 específicamente, por ejemplo).
Teniendo esto en cuenta, veo por tanto poco probable que los desarrolladores de distros orientadas a máquinas viejas inviertan tiempo en preparar nuevas versiones del kernel compatibles con esas máquinas.
En principio no tendría que ser un problema si lo que hacen es simplemente dejar versiones viejas del kernel y actualizar las aplicaciones, pero habrá un momento en que las aplicaciones no funciones con versiones viejas del kernel.
Eso quiere decir que lo más probable es que esas distros orientadas a máquinas antiguas se dividan en dos grupos:
- Unas que se centren en procesadores Pentium 2 o superiores y mantengan versiones actualizadas de todo
- Otras que se centren en procesadores 486 y primera generación de Pentium (muy nicho), con una versión del kernel no actualizada, y versiones de aplicaciones o bien no actualizadas o bien personalizadas para ejecutarse en con esas versiones del kernel.
El artículo menciona: "A excepción de la licencia GPLv3, en general, Open Source no es libre"
El 90% de las licencias consideradas Open Source, incluyendo GPL 2 y 3, LGPL 2 y 3, AGPL, las BSD, las de Apache, las mayoria de las que tienen algún proyecto específico, etc son consideradas libres y viceversa.
Listado de licencias consideradas Open Source por la OSI: opensource.org/license
Listado de licencias consideradas libres por las FSF: www.gnu.org/licenses/license-list.html
De hecho la mayoría de las que menciona la FSF como no libres no son consideradas Open Source por la OSI. Hay excepciones como el caso de la NASA Open Source license que la FSF no considera libre ya que no te permite añadir código no creado por tí mientras que la OSI la considera Open Source igualmente, pero son casos muy aislados.
#3 Tal y como comenta el artículo, el software puede ser ecológico si optimiza los recursos del hardware para que consuma menos energía y se optimiza para funcionar correctamente en equipos antiguos para que así la gente tenga que renovar sus equipos con menos frecuencia.
#9 Algunas aclaraciones:
- No hay que esperar un año para que se publique una versión de Qt, The Qt Company ha anunciado considerarlo como posibilidad, pero parece que se ha echado atrás.
- Efectivamente, va en contra de lo que sería la filosofía de contribuir con el software libre. Si lo hiciesen, la publicación dentro de un año no sería por colaborar con el software libre, si no porque sería la forma de cumplir "técnicamente" con un contrato que tienen firmado con KDE.
- Es bastante probable que nunca hubiesen valorado realmente restringir la publicación de versiones libres, si no que simplemente fuese una amenaza en las negociaciones a KDE en plan "O cambiamos el contrato o lanzamos la versión libre de Qt con un año de retraso" para que KDE entrase en pánico y haya tenido el efecto contrario
#22 Depende un poco como lo veas. Red Hat tenía mucha presencia (y la sigue teniendo) en América pero no tanta en Europa. La gente que comenzaba a usar GNU/Linux solían usar Mandrake o SuSE, la gente con más experiencia Debian.
En cualquier caso, era bastante usual que la muchas distribuciones ejecutasen un gestor de paquetes antes de proceder a la instalación para que se eligiese el software que se quería instalar los paquetes disponibles durante el proceso de instalación, por lo que no era tan importante qué escritorio iba por defecto en una distribución ya que si lo preferías podías marcar otro.
Creo que esto sí es algo que cambió como consecuencia del modelo de instalación que propuso Ubuntu: El entorno y el software por defecto que incorporaba la distro pasó a ser mucho más relevante.
#13 No sé si en 2007 Debian incorporaba GNOME por defecto, pero si hablamos de antes de Ubuntu, Ubuntu fue publicada en 2004. Por aquel entonces la versión de Debian era Woody que creo que no instalaba GNOME ni KDE por defecto.
#2 No estoy de acuerdo con que en aquel momento GNOME fuese la distribución por defecto en las principales distribuciones. Redhat y Fedora instalaban GNOME por defecto. Pero otras muchas (ejemplo: SuSE, Mandrake, Knoppix) instalaban KDE por defecto.
#4 Debian no instalaba por defecto ni KDE ni GNOME (aunque sí incluía ambos en los repositorios, tenías que instalarlos manualmente) y de hecho creo que tampoco instalaba X11 por defecto.
#9 fid 