La fecha de lanzamiento de la actualización 4 de RHEL 4 es incorrecta.
Respuesta: El anuncio de [email protected] se envió el 11 de agosto de 2006. Lo modifiqué en consecuencia. Riaanvn 19:29, 14 de octubre de 2006 (UTC) [ responder ]
Agregué las fechas de lanzamiento de la versión beta y corregí la fecha de lanzamiento de la versión 5.3. Estas fechas se obtuvieron al volver a leer los comunicados de prensa oficiales de Redhat. —Comentario anterior sin firmar agregado por 153.2.246.32 ( discusión ) 13:43, 19 de marzo de 2010 (UTC) [ responder ]
No creo que RHL 6.2E deba mencionarse en la historia de RHEL. Sería más correcto decir que Red Hat comenzó a preocuparse por las empresas con esta versión de RHL y, a partir de entonces, hizo una oferta realmente adaptada a las empresas con RHEL.
- Tal vez tengas razón. No estoy seguro de si "preocuparse" por las empresas fue su motivo o si tenían una intención diferente cuando cambiaron de RHL a RHEL. Sin embargo, no estoy de acuerdo con que RHL 6.2E deba omitirse de la historia, porque muestra un momento clave en el que se tomó la decisión de cambiar la marca de su producto de RHL a RHEL. -- pr o xx z talk 13:03, 29 de septiembre de 2020 (UTC) [ responder ]
(desde: http://www.redhat.com/rhel/ ) ... Tenga en cuenta que las variantes AS, ES y WS proporcionadas por versiones anteriores de Red Hat Enterprise Linux no están disponibles para la versión 5. Los reemplazos directos para todos estos productos se proporcionan con la versión 5. Consulte la información de actualización para obtener más detalles.
-- Fedkad 08:08, 23 de marzo de 2007 (UTC) [ responder ]
NO puedes descargar RHEL a menos que compres una suscripción determinada. ¿El código fuente de RHEL está disponible después de comprarlo? ¿Es legal en términos de la GPL de LINUX?
- Sí, porque el código fuente está disponible de forma gratuita (de ahí que existan clones). El código abierto no significa gratuito (como la cerveza).
Sí. Todo lo que tienen que hacer bajo la licencia GPL es proporcionar el código fuente (ya sea por correo postal por un pequeño costo de envío) o en línea. De hecho, Redhat es muy servicial y proporciona el código fuente en formato SRPM en su servidor FTP, así como con las copias empaquetadas del software.
Código abierto no es igual a gratuito.
Tienen perfecto derecho a cobrar por el producto binario compilado siempre que el código fuente esté disponible. —Comentario anterior sin firmar añadido por 134.36.93.46 ( discusión ) 03:30, 21 de mayo de 2009 (UTC) [ responder ]
- Como dice el artículo, la mayor parte de RHEL es software libre, pero hay marcas comerciales y obras de arte que no son libres y que deben eliminarse para permitir su redistribución. Incluir material libre y no libre en una distribución Linux se considera que cae dentro del término de "mera agregación" de la GPL, por lo que está bien en ese sentido. 130.88.108.187 ( discusión ) 10:16 10 ago 2011 (UTC) [ responder ]
- No soy abogado (y sí, trabajo para Red Hat), pero en mi humilde opinión, todo el movimiento de software libre (a diferencia del de cultura libre) trata de la libertad del código fuente de las computadoras. Nadie garantiza que cualquier obra de arte sea libre. En mi humilde opinión, es el mismo error por el que creo que la gente que está en Debian y argumenta que Firefox no es libre (ver el alboroto en torno a IceWeasel ) está equivocada. De nuevo, no hablo en nombre de mi empleador, etc. Ceplm ( discusión ) 09:37, 24 de enero de 2015 (UTC) [ responder ]
Re: Pregunta: ¿RHEL es *realmente* de código abierto o no?
Creo que tienes acceso al código fuente desde el sitio ftp de Red Hat (ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/), sin necesidad de registrarse ni nada.
Cabe señalar que CentOS ([1]) es una reconstrucción no comercial de RHEL a partir de la fuente: simplemente elimina la marca y el diseño gráfico de Redhat. Muchas empresas que desean la estabilidad de RHEL pero no quieren pagar por ella utilizan CentOS en su lugar. —Comentario anterior sin firmar agregado por ChrisKurtz ( discusión • contribuciones ) 17:27, 2 de enero de 2008 (UTC) [ responder ]
¿Alguien más ha notado que en RHEL4 Desktop se tiene todo el material de desarrollo, bibliotecas de desarrollo, gcc, emacs, autoconf, php, apache, pero ahora en RHEL5 no se tiene todo eso con Desktop, sino que se necesita Workstation? Sin embargo, no puedo encontrar una referencia para esto. Rythie 14:52, 27 de julio de 2007 (UTC) [ responder ]
- No tengo ninguna referencia específica sobre lo que se eliminó entre Desktop 4 y Desktop 5, pero esta página ofrece una buena comparación entre las variantes de Desktop, incluso indicando que la opción Workstation "incluye la pila de desarrollo de software Red Hat Enterprise Linux". Riaanvn 19:01, 11 de noviembre de 2007 (UTC) [ responder ]
En 3 y 5 solo se obtienen herramientas de desarrollo con la estación de trabajo. ¿Quizás te equivocas o la versión 4 fue un cambio? —Comentario anterior sin firmar agregado por 134.36.93.46 ( discusión ) 03:33, 21 de mayo de 2009 (UTC) [ responder ]
Vale, la primera línea del artículo dice que no es correcto referirse a Red Hat Enterprise Linux como RHEL, al igual que la primera referencia citada. Pero luego se hace referencia al producto constantemente como "RHEL" en el resto del artículo. ¿Qué pasa con eso? —Comentario anterior sin firmar agregado por 65.24.162.97 (discusión • contribuciones ) 21:24, 27 de febrero de 2008
- Probablemente porque agregué la referencia, pero no modifiqué cada referencia de RHEL a lo largo del artículo. Puedes hacerlo tú mismo si lo deseas. ~~ [Jam] [discusión] 01:06, 28 de febrero de 2008 (UTC) [ responder ]
- Hecho —Comentario anterior sin firmar añadido por 65.24.162.97 (discusión) 01:46, 28 de febrero de 2008 (UTC)[ responder ]
"Red Hat Enterprise Linux se abrevia a menudo como RHEL, pero Red Hat ahora está intentando desalentar esto. [1]" Lea el artículo... me parece que ese es el punto de vista de algunas personas dentro de Red Hat y no es obligatorio, creo que esta línea debería eliminarse, solo mire la URL de Red Hat Enterprise Linux... contiene RHEL; si no quieren RHEL deberían ser los primeros en eliminar RHEL del sitio web de Red Hat. Nuevamente: Eliminar el uso de RHEL me parece que es el punto de vista de algunas personas. —Comentario anterior sin firmar agregado por 201.247.28.25 ( discusión ) 17:30, 8 de junio de 2008 (UTC) [ responder ]
- De hecho, todo esto es un poco tonto, en realidad. Incluso si RH (ya saben, Red Hat ) se pone nerviosa por esto, no les corresponde a ellos decidir cómo se llama a su producto. Está dentro del alcance de una enciclopedia abreviar términos largos, y repetir el uso popular debería ser aceptable aquí, siempre que se presente como tal. A menos, por supuesto, que este sea un artículo de vanidad. -- Rfsmit ( discusión ) 16:36, 17 de septiembre de 2008 (UTC) (editado -- Rfsmit ( discusión ) 16:51, 17 de septiembre de 2008 (UTC)) [ responder ]
2009-01-20 Tim Burke, director sénior de ingeniería de software de Red Hat, dice en un vídeo que cubre las características clave de la nueva versión RHEL 5.3: "Cada versión menor de RHEL tiene una... tiene una evolución de las características de administración de energía, por lo que nos volvemos cada vez más ecológicos". No estoy haciendo campaña para deshacer las dos revisiones de 65.24.162.97 del 27 de febrero de 2008; sólo estoy señalando que ellas, especialmente la primera, fueron un esfuerzo desperdiciado. -- Rfsmit ( discusión ) 23:22, 21 de enero de 2009 (UTC) [ responder ]
¿No utiliza este sistema operativo el superordenador más rápido? Creo que el superordenador es propiedad de IBM. Esto podría quedar bien en el artículo... —Comentario anterior sin firmar añadido por 72.218.12.31 (discusión) 22:20, 10 de junio de 2008 (UTC) [ responder ]
- Si puedes encontrar una referencia al mismo, entonces se puede incluir. ~~ [Jam] [discusión] 22:23 10 jun 2008 (UTC) [ responder ]
- Lo mismo dice la sección de actualidad de la página principal de Wikipedia de hoy. Brentt ( discusión ) 22:55 10 jun 2008 (UTC) [ responder ]
- Bueno, no vi el artículo de la página de inicio y el uso de RHEL no se menciona en el artículo en sí. Tengo una fuente de InformationWeek (http://www.informationweek.com/news/hardware/supercomputers/showArticle.jhtml?articleID=208402904) que dice que ejecuta "Red Hat Linux" (que probablemente se referían a RHEL). ~~ [Jam] [discusión] 23:06 10 jun 2008 (UTC) [ responder ]
En Variantes : A veces, la gente se refiere erróneamente a ES como "Enterprise Server" . Si Red Hat no ha definido lo que significa la marca "ES", y especialmente considerando que la marca cubre un producto de servidor empresarial, entonces no es un error asumir que "ES" significa "Enterprise Server". Es una suposición. Referirse a este uso como erróneo es un punto de vista. Reformulado apropiadamente. -- Rfsmit ( discusión ) 16:47, 17 de septiembre de 2008 (UTC) [ responder ]
Si visita su 'tienda' en línea [1] , encontrará que los tres tipos que venden son Servidor, Escritorio, Estación de trabajo. Dentro de Escritorio y Estación de trabajo, puede obtener diferentes paquetes de soporte. Dentro de servidor, hay más opciones, debido a la variedad de arquitecturas y alcance. Red Hat Enterprise Linux Server para x86 de 32/64 bits, Red Hat Enterprise Linux para centros de datos virtuales, Red Hat Enterprise Linux Server para IBM POWER, Red Hat Enterprise Linux para IBM System z. Dentro de cada uno de estos tipos hay varios subtipos basados en la cantidad de sockets físicos, la inclusión del complemento de administración inteligente y el nivel de soporte. Básicamente, "AS", "ES", "WS" ya no se utilizan. (05OCT2016) Xalorous ( discusión ) 12:05, 5 octubre 2016 (UTC) [ responder ]
Referencias
- ^ https://www.redhat.com/wapps/store/allProducts.html
En Version_history agregué "3u8" y "4u4", ya que estas notaciones son muy comunes en la web pero no se mencionaron aquí. Me tomó 20 minutos buscar en Google qué significaban; había muchas referencias, pero ninguna definición. Supongo que, en teoría, esta regla general podría explicarse arriba, pero tener todas las abreviaturas reales al lado de cada una ayudaría a los motores de búsqueda a recordarlas.
También sería bueno ver definiciones o enlaces a los distintos sufijos (AS, ES) y versiones con nombre en código (Pensacola, etc.); por ahora, los enlaces llevan a las ciudades geográficas reales, en lugar de a una página que habla sobre el uso que hace Red Hat del nombre de esa ciudad en su nombre en código. Me doy cuenta de que algunos gurús de Unix consideran que esto es "obvio" y bien conocido, pero para aquellos que no están familiarizados con los términos, esta wiki debería explicarlo.
No creo ser lo suficientemente gurú como para explicarle todo esto al mundo, pero ¿quizás alguien más aquí lo sea? —Comentario anterior sin firmar agregado por Ttennebkram ( discusión • contribuciones ) 17:01, 10 de diciembre de 2008 (UTC) [ responder ]
Sería bueno analizar las diferentes convenciones de nombres de las versiones. Por ejemplo, existe la versión 5.1 frente a la 5.2, y luego están "QU1" y "QU2" (actualización trimestral). No he encontrado ninguna documentación de RH sobre lo que significa realmente "QU", salvo una referencia a que se trata de una "actualización trimestral". -- Paul (discusión) 21:08, 20 de enero de 2009 (UTC) [ responder ]
,.. —Comentario anterior sin firmar añadido por 202.54.160.11 (discusión) 14:51, 1 de septiembre de 2009 (UTC) [ responder ]
¿Es realmente apropiada esta sección en este artículo? Esta idea de que las versiones de RHEL se generan de alguna manera a partir de una determinada versión de RHL o Fedora no es precisa. RHEL se basa en las versiones de aplicaciones que se ha demostrado que son estables juntas. Fedora SÍ sirve como banco de pruebas para Redhat, pero es una prueba aplicación por aplicación, no una prueba del tipo "Fedora 4 se convertirá en RHEL 4". Además, cada una de estas listas es diferente según a quién le preguntes. No hay ningún documento oficial citable de Redhat que describa la relación, por lo que creo que esta sección debería eliminarse. Meton magis ( discusión ) 06:02, 1 de diciembre de 2009 (UTC) [ responder ]
Se han hecho algunas modificaciones sobre cuándo se lanzará Red Hat 6. ¿Existen fuentes fiables para ello? La modificación que acabo de eliminar decía que se basaba en Fedora 14, el kernel 2.6.38 y que se lanzaría en el tercer trimestre de 2011, lo que sospecho que es completamente inventado. -- JSBillings 16:21, 2 de diciembre de 2009 (UTC) [ responder ]
- He editado el material de la versión RHEL 6. Según Tim Burke, vicepresidente de ingeniería de Red Hat Enterprise Linux, RHEL 6 está en desarrollo, pero no se han establecido fechas ni versiones de kernel ni nada de eso. Consulte http://www.redhat.com/f/pdf/summit/tburke_1050_rhel_roadmap.pdf para ver la hoja de ruta que presentó en Red Hat Summit 2009. Thomascameron (discusión) 16:58 2 dic 2009 (UTC) [ responder ]
- ¡Gracias a Davidbspalding y Thomascameron por encontrar una referencia y limpiar la página! -- JSBillings 20:05, 2 de diciembre de 2009 (UTC) [ responder ]
Una publicación en el foro http://www.linuxquestions.org/questions/red-hat-31/when-we-shall-expect-rhel-6-a-711537/page2.html indica que la fecha de lanzamiento puede ser en septiembre. Sin embargo, esta fuente está tan lejos de ser fidedigna que apenas vale la pena mencionarla. Dicho esto, lo único que he visto es Roomer. -- Paul (discusión) 15:30 14 jul 2010 (UTC) [ responder ]
Supongo que la cagaron con esa suposición descabellada, ¿eh? Fnj2 ( discusión ) 16:06 7 oct 2010 (UTC) [ responder ]
Tal vez se debería mencionar RHN . Es muy relevante para RHEL, ya que es una forma muy común de administrar en masa los equipos RHEL. -- Paul (discusión) 15:40, 14 de julio de 2010 (UTC) [ responder ]
Mi idea es que el párrafo introductorio es demasiado largo. ¿Algún lector está de acuerdo con eso? -- Kittyhawk2 ( discusión ) 03:54 25 ago 2010 (UTC) [ responder ]
- El párrafo o la sección. El primer párrafo tiene solo 3 oraciones. El prólogo en sí tiene demasiados párrafos, pero eso se debe simplemente a que no se ha dividido bien en párrafos, con algunos párrafos de una sola oración. Yworo ( discusión ) 04:24 25 ago 2010 (UTC) [ responder ]
Estoy confundido con esta afirmación. ¿Cómo se puede considerar ofuscación el hecho de no proporcionar parches? ¿Acaso cualquiera que lo desee no podría simplemente ejecutar una herramienta de diferencias para obtener los archivos de parches de todos modos? ¿En qué se diferencia esto? Hiiiiiiiiiiiiiiiiiiiiii ( discusión ) 04:05, 3 de julio de 2011 (UTC) [ responder ]
- Sin duda, una comparación funcionaría si solo quisieras saber todos los cambios. La diferencia con el comportamiento anterior era que Red Hat proporcionaba cientos de parches, cada uno con una característica particular que se estaba incorporando o integrando, de modo que otros proveedores (léase Oracle) podían elegir qué característica incorporar a su propio paquete de kernel. Red Hat sigue manteniendo estos parches, pero ya no son públicos. -- JSBillings 14:16, 3 de julio de 2011 (UTC) [ responder ]
- A menudo se supone que las marcas ES y AS significan "Entry-level Server" y "Advanced Server", respectivamente. [...] Sin embargo, en ningún lugar de su sitio o en su documentación Red Hat dice qué significan AS, ES y WS.
¿Quién escribió esto? Me tomó 10 segundos encontrarlo...
"Red Hat Enterprise Linux AS (anteriormente Red Hat Linux Advanced Server)". http://www.redhat.com/whitepapers/rhel/AdvServerRASMpdfRev2.pdf
"Red Hat Enterprise Linux ES (“servidor de nivel de entrada/medio”)" http://www.redhat.com/whitepapers/rhel/RHEL3FamOverWPSO.pdf 70.168.250.62 ( discusión ) 20:44 9 ago 2011 (UTC) [ responder ]
^ Tal vez cuando el autor escribió eso no lo decía en el sitio, pero ahora lo dice de nuevo. Raindr ( discusión ) 07:10 18 abr 2012 (UTC) [ responder ]
Hola compañeros wikipedistas,
Acabo de agregar enlaces de archivo a un enlace externo en Red Hat Enterprise Linux . Tómese un momento para revisar mi edición. Si es necesario, agregue después del enlace para evitar que lo modifique. Alternativamente, puede agregar para mantenerme fuera de la página por completo. Hice los siguientes cambios:{{cbignore}}
{{nobots|deny=InternetArchiveBot}}
- Se agregó el archivo https://web.archive.org/20091008223755/http://www.redhat.com/rhel/moving/ a https://www.redhat.com/rhel/moving/
Cuando haya terminado de revisar mis cambios, configure el parámetro marcado a continuación como verdadero para informar a los demás.
Y Un editor revisó esta edición y corrigió todos los errores encontrados.
- Si ha descubierto URL que el bot consideró erróneamente como muertas, puede informarlas con esta herramienta.
- Si encuentra un error con algún archivo o con las URL en sí, puede solucionarlo con esta herramienta.
Saludos.— cyberbot II Habla con mi dueño :En línea 00:44, 7 de enero de 2016 (UTC) [ responder ]
- Listo , está bien. — Dsimic ( discusión | contribs ) 12:45 4 feb 2016 (UTC) [ responder ]
Hola compañeros wikipedistas,
Acabo de modificar un enlace externo en Red Hat Enterprise Linux . Tómese un momento para revisar mi edición. Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página en su totalidad, visite esta sencilla sección de preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:
- Se agregó el archivo http://web.archive.org/web/20140224120105/http://www.redhat.com:80/products/enterprise-linux-add-ons/extended-lifecycle-support/ a https://www.redhat.com/products/enterprise-linux-add-ons/extended-lifecycle-support/
Cuando haya terminado de revisar mis cambios, configure el parámetro marcado a continuación como verdadero o no para informar a los demás (documentación en ).{{Sourcecheck}}
Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular utilizando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulte la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}
- Si ha descubierto URL que el bot consideró erróneamente como muertas, puede informarlas con esta herramienta.
- Si encuentra un error con algún archivo o con las URL en sí, puede solucionarlo con esta herramienta.
Saludos.— cyberbot II Habla con mi dueño :En línea 20:51, 27 de junio de 2016 (UTC) [ responder ]
Actualmente hay una discusión sobre si Template:Infobox OS debería usarse con múltiples números de versión - por ejemplo, para listar tanto una versión beta de "actualización de software" como una de "próxima versión principal", o para listar versiones beta de más de una secuencia de versiones. Si crees que múltiples versiones {estable, preview} nunca deberían aparecer en ese infobox, o si crees que deberían aparecer en algunas o todas las circunstancias en las que hay más de una versión beta del SO en cuestión disponible, es posible que quieras comentar allí. (No tengo una opinión firme de ninguna de las dos cosas; estoy de acuerdo con que la página principal del SO incluya solo la versión beta de "próxima versión principal", pero incluya versiones beta de múltiples secuencias si existen, pero también estaría de acuerdo con otras opciones). Guy Harris ( discusión ) 08:17 11 jul 2016 (UTC) [ responder ]
Hola compañeros wikipedistas,
Acabo de modificar dos enlaces externos en Red Hat Enterprise Linux . Tómese un momento para revisar mi edición. Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página en su totalidad, visite esta sencilla sección de preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:
- Formato y uso corregidos para https://www.redhat.com/about/presscenter/2000/press_enterprise.html
- Se agregó el archivo https://web.archive.org/web/20140427065858/http://www.redhat.com/about/news/archive/2014/4/red-hat-enterprise-linux-7rc-available a https://www.redhat.com/about/news/archive/2014/4/red-hat-enterprise-linux-7rc-available
Cuando haya terminado de revisar mis cambios, puede seguir las instrucciones de la plantilla a continuación para solucionar cualquier problema con las URL.
Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular utilizando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulte la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}
- Si ha descubierto URL que el bot consideró erróneamente como muertas, puede informarlas con esta herramienta.
- Si encuentra un error con algún archivo o con las URL en sí, puede solucionarlo con esta herramienta.
Saludos.— InternetArchiveBot ( Reportar error ) 19:49, 14 de septiembre de 2017 (UTC) [ responder ]
Normalmente utilizo este artículo para hacer referencia a las fechas de lanzamiento, que, para ser sincero, podría encontrar en otro lugar; pero me resulta extremadamente difícil buscar las primeras fechas de lanzamiento de la versión beta para cada versión puntual, con el fin de quejarme ante los desarrolladores externos de que "han tenido tanto tiempo desde la versión beta XY" para arreglar su software o algo similar. Creo que también sería valioso para otros fines (entre ellos, un registro de cuánto tiempo cada versión puntual permanece en versión beta). Tal vez se podría "introducir" en este tema en una conversación y luego hacer una revisión rápida para ver si pertenece al artículo principal. ¿Opiniones? -- Rfsmit ( discusión ) 19:38, 25 de agosto de 2020 (UTC) [ responder ]
- Acabo de mirar su página de lanzamientos y no dice nada sobre los lanzamientos beta. También encontré una pequeña página de noticias sobre los lanzamientos beta, pero no hay mucha información allí. -- pr o xx z talk 13:23, 29 de septiembre de 2020 (UTC) [ responder ]
Un comunicado de prensa de RedHat enumera cómo se relacionan Fedora y CentOS con RedHat Enterprise Linux.
El texto relevante:
Estamos convirtiendo CentOS Stream en el centro de colaboración para RHEL, con un panorama similar al siguiente:
- Fedora Linux es el lugar de las principales innovaciones, pensamientos e ideas sobre sistemas operativos; esencialmente, aquí es donde nace la próxima versión principal de Red Hat Enterprise Linux.
- CentOS Stream es la plataforma de entrega continua que se convierte en la próxima versión menor de RHEL.
Entonces, cuando estás ejecutando RedHat Enterprise Linux y quieres saber de dónde proviene el desarrollo:
RHEL 8.2 proviene de Fedora, mientras que 8.2 proviene de CentOS — Comentario anterior sin firmar agregado por Tyraz ( discusión • contribuciones ) 12:41, 10 de febrero de 2021 (UTC) [ responder ]
Una edición anónima reciente del artículo cambió el artículo para decir que CentOS Stream es ahora el upstream para RHEL, no Fedora.
https://en.wikipedia.org/w/index.php?title=Red_Hat_Enterprise_Linux&diff=next&oldid=1035664570
En realidad, ambos son upstream para RHEL. Fedora es upstream para nuevas versiones principales y CentOS Stream es upstream para nuevas versiones secundarias. Tengo un COI revelado para este artículo, por lo que quería iniciar una discusión aquí sobre la edición del artículo para reflejar esas relaciones.
Carlwgeorge ( discusión ) 22:34 20 ago 2021 (UTC) [ responder ]
Últimamente, Red Hat esconde el código fuente detrás de un muro de pago. Como alguien ha revertido mi edición por razones desconocidas, informo que esta decisión, técnicamente, no viola la GPL. Sin embargo, el tema controvertido es prohibir la redistribución del código fuente, amenazando con cancelar la suscripción. En esta misma FAQ, dice claramente que un acuerdo independiente (como NDA) que prohíba esto, puede violar la GPL. Lamentablemente, no encontré ninguna información sobre cómo se implementa en el caso de Red Hat. Si alguien quiere encontrar otro caso de estudio, sugiero gsecurity. Twomithe ( discusión ) 15:42, 29 de junio de 2023 (UTC) [ responder ]
- No solo está prohibida la redistribución del código fuente, tampoco se pueden redistribuir binarios.
- "Todo software es software disponible en código fuente siempre que su código fuente se distribuya junto con él, incluso si el usuario no tiene derechos legales para usarlo, compartirlo, modificarlo o incluso compilarlo".
- Técnicamente tienen derechos legales.
- Yo diría que esta es una zona muy gris Original-ish-username (discusión) 13:26 3 jul 2023 (UTC) [ responder ]
- Red Hat dice que CentOS Stream es el repositorio de código fuente ahora, pero en este momento NO es RHEL, por lo que estoy pensando en cambiar de código abierto a código fuente disponible. Quetstar ( discusión ) 22:44, 5 de julio de 2023 (UTC) [ responder ]
- La mejor fuente que pude encontrar, Software Freedom Conservancy, concluye expresando su preocupación por la dificultad de supervisar el cumplimiento de la GPL por parte de RHEL debido al temor a perder contratos de servicio y a las solicitudes de informes sobre infracciones relacionadas con RHEL, porque IBM rechazó las solicitudes de SFC. Por lo tanto, el asunto sigue sin resolverse y, por el momento, no hay pruebas contundentes de que se trate de un producto con código fuente disponible. Twomithe ( discusión ) 09:39, 8 de julio de 2023 (UTC) [ responder ]
- Por eso debería estar marcado como fuente disponible, porque no hay forma de verificar el cumplimiento. Quetstar ( discusión ) 15:48 9 jul 2023 (UTC) [ responder ]
- Si algo no es verificable, significa que no debería estar en Wikipedia . Según el falibilismo, esto solo debería cambiarse cuando surjan nuevas evidencias. Twomithe ( discusión ) 17:54 11 jul 2023 (UTC) [ responder ]
- No hay forma de verificar que RHEL realmente cumpla con sus licencias FOSS, por lo que no debería marcarse como código abierto. Quetstar ( discusión ) 19:17, 11 de julio de 2023 (UTC) [ responder ]
- Vaya respuesta, me encanta mucho Gatolocosess (discusión) 22:19 11 jul 2023 (UTC) [ responder ]
- En el estado actual, sabemos que no se debe violar la GPL. Si surge nueva evidencia o si se tienen mejores fuentes, se deben agregar, sin cambiar sin la información sin fuentes. Twomithe ( discusión ) 11:24 12 jul 2023 (UTC) [ responder ]
- Pero la fuente de Red Hat es primaria, necesitamos una secundaria para verificar esto. Para su información, la SFC ha declarado que debido a los cambios, es difícil verificar el cumplimiento de la GPL. Quetstar ( discusión ) 16:25 12 jul 2023 (UTC) [ responder ]
- Si la SFC no puede confirmar nada sobre este asunto, estoy bastante seguro de que la mayoría de los demás son meros profanos que se limitan a especular. Twomithe ( discusión ) 17:31 12 jul 2023 (UTC) [ responder ]
- He convocado una convocatoria de propuestas sobre el asunto, por lo que pronto se resolverá. Quetstar ( discusión ) 17:38 12 jul 2023 (UTC) [ responder ]
- La siguiente discusión es un registro archivado de una solicitud de comentarios . No la modifique. No se deben realizar más modificaciones a esta discusión. A continuación se incluye un resumen de las conclusiones a las que se llegó.
El resultado fue describir el modelo fuente como
de código abierto .
Aaron Liu (
discusión ) 03:58 21 jul 2023 (UTC)
[ responder ]
Como ya sabrás, Red Hat decidió recientemente dejar de poner a disposición del público el código fuente de RHEL. Por lo tanto, es difícil verificar el cumplimiento de RHEL con sus licencias FOSS. La pregunta es: ¿el modelo de código fuente de RHEL debería describirse como de código abierto o de código disponible? Quetstar ( discusión ) 16:42 12 jul 2023 (UTC) [ responder ]
- Personalmente, prefiero "código abierto", ya que no significa que deba estar disponible de forma gratuita y los cuadros de información deben ser breves. Sin embargo, me gustaría escuchar otras opiniones. Aaron Liu ( discusión ) 18:47 12 jul 2023 (UTC) [ responder ]
- Solo quiero agregar que las distribuciones derivadas directas como Rocky Linux lograron encontrar una solución alternativa al muro de pago, utilizando imágenes de contenedores UBI e instancias de nube pública de pago por uso [1] , y probablemente nadie sabrá cuán legal es hasta que haya alguna demanda. Twomithe ( discusión ) 04:08, 13 de julio de 2023 (UTC) [ responder ]
- Citando el artículo de The Register [2]:
Red Hat ha decidido dejar de poner a disposición del público el código fuente de RHEL. A partir de ahora, solo estará disponible para los clientes, quienes no pueden compartirlo legalmente.
Mientras tanto, nuestro artículo define el software de código abierto como software informático que se publica bajo una licencia en la que el titular de los derechos de autor otorga a los usuarios los derechos de uso, estudio, modificación y distribución del software y su código fuente a cualquier persona y para cualquier propósito.
Observe cómo The Register dice que los clientes no pueden compartir legalmente el código fuente. - Si quieres otra fuente, Red Hat dice que el software de código abierto [3]
es un código diseñado para ser de acceso público: cualquiera puede verlo, modificarlo y distribuirlo como crea conveniente.
Esto ya no es así, por lo que Rhel no es de código abierto según su propia definición . - RHEL está disponible en código fuente en el mejor de los casos. Ajedrez ( discusión ) (por favor, mencióname en la respuesta) 19:37 13 jul 2023 (UTC) [ responder ]
- No creo que RHEL deba describirse como código fuente disponible. Se trata de una zona gris legal y cualquier cambio que se haga aquí debe estar respaldado por fuentes creíbles. Red Hat todavía parece pensar que RHEL es de código abierto y no hay muchas fuentes creíbles que afirmen que no lo es. Incluso si no describimos a RHEL como código fuente disponible, esto plantea la cuestión de si se deben mantener las menciones a que RHEL es FOSS. Creo que se deben mantener, ya que el consenso general actual es que RHEL es de código abierto, al menos en el sentido de que técnicamente no viola la GPL.
- Aparte de eso, hasta donde yo sé, hay tres argumentos principales a favor de describir a RHEL como software de código abierto: (1) la GPL no exige que el código fuente esté disponible para todos, sólo para aquellos que tienen el software (y no, no sólo los clientes de Red Hat), (2) el acuerdo de RH de que la distribución restringida de RHEL existe desde hace años y no ha afectado al estatus de código abierto de RHEL hasta ahora, y (3) la GPL sigue vigente y el acuerdo de RH es un documento legal independiente que no la reemplaza. Para ampliar el punto (3), redistribuir RHEL viola el acuerdo de RH y puede provocar su terminación, pero no termina la GPL, que está en plena vigencia independientemente del acuerdo. Una prueba de ello es que nadie ha necesitado nunca una suscripción a RHEL para obtener el código fuente. Alguien puede distribuirte RHEL y luego puedes escribirle a Red Hat por correo postal y te enviarán el código de vuelta (a cambio de un cargo), de conformidad con la Sección 3(b) de la GPLv2. Choclei ( discusión ) 21:42 13 jul 2023 (UTC) [ responder ]
- Estoy de acuerdo. Todas las partes de la definición que cita @Chess se cumplen técnicamente y la mayoría de las fuentes confiables no niegan que sea de código abierto. Aaron Liu ( discusión ) 22:35 13 jul 2023 (UTC) [ responder ]
- "No negar" no significa que sea de código abierto. Me gustaría ver citas que demuestren que es de código abierto. Y la definición no se ha "cumplido técnicamente", Red Hat (la empresa) dice que el código abierto
es un código que está diseñado para ser de acceso público
y que actualmente no es de acceso público. Chess ( discusión ) (por favor, mencióname en la respuesta) 00:01 14 jul 2023 (UTC) [ responder ]
- Si su condición de distribución de código abierto es una zona gris, no deberíamos decir que lo es. WP:ONUS es demostrar que Red Hat es una distribución de código abierto, y las fuentes no lo dicen. En respuesta a
Red Hat todavía parece pensar que RHEL es de código abierto
, proporcione algunas referencias a Red Hat o, preferiblemente, a alguien que no sea Red Hat, dado que Red Hat realmente odia que su distribución no se llame de código abierto. - Su afirmación de que
alguien puede distribuirle RHEL y que luego usted puede escribirle a Red Hat por correo postal y ellos le enviarán el código de vuelta (a cambio de un cargo), de conformidad con la Sección 3(b) de la GPLv2,
no se basa en la realidad. Le estoy proporcionando una fuente confiable que contradice directamente su afirmación sin fuentes. The Register dice que Red Hat ha decidido dejar de poner a disposición del público el código fuente de RHEL.
"Código abierto" significa que el código fuente está disponible abiertamente. - La definición de código abierto de la OSI es que
la licencia debe permitir modificaciones y trabajos derivados, y debe permitir que se distribuyan bajo los mismos términos que la licencia del software original.
[4] A partir de ahora, The Register dice que el código fuente de RHEL solo estará disponible para los clientes, quienes no pueden compartirlo legalmente.
- Lo que dices debería considerarse como WP: investigación original si no proporcionas ninguna cita. Ajedrez ( discusión ) (por favor, mencióname en la respuesta) 23:59, 13 de julio de 2023 (UTC) [ responder ]
- @ Chess Bueno, esa es la definición de OSI. Pero esto demuestra que se trata de una zona gris con múltiples definiciones (¿contradictorias?). No todas las definiciones coinciden en que puede ser gratuito. Además, The Register no contradice esa afirmación; si bien se trata de una fuente primaria, la GPL no limita el precio de la cesión al público y permite a la gente redistribuirlo de forma gratuita. TL;DR: Choclei tiene razón al decir que se permite dar el código a cualquiera de forma gratuita después de obtenerlo pagando a RedHat o consiguiéndolo de algún otro lugar.Al menos RHEL era una distribución de código abierto. Dado que existe ONUS y tenemos fuentes de esa época que establecen que es de código abierto, la ONUS en realidad recae sobre usted para proporcionar fuentes confiables que indiquen directamente que RHEL no es de código abierto. Decir que "dejar de hacer que el código fuente de RHEL esté disponible para el público" equivale a "no es de código abierto" es una investigación original. Aaron Liu ( discusión ) 01:19 14 jul 2023 (UTC) [ responder ]
- ¿Estás hablando de WP:BURDEN , como si la carga de la prueba recayera sobre quienes afirman que RHEL es de código abierto? Si es así, en realidad creo que la carga de la prueba recae sobre quienes afirman que RHEL no es de código abierto. La afirmación de que RHEL es de código abierto es verificable y se hace referencia a ella correctamente en este artículo. Ese es el status quo. Se ha hecho una nueva afirmación ('RHEL ya no es de código abierto') y esa es la que se debe probar ahora. Choclei ( discusión ) 01:51, 14 de julio de 2023 (UTC) [ responder ]
- El problema es que las Condiciones de servicio de RHEL prohíben la redistribución del código fuente y los binarios. Quetstar ( discusión ) 02:19, 14 de julio de 2023 (UTC) [ responder ]
- Por favor, vea mi respuesta a continuación. Si, según el EULA de RH, RHEL está efectivamente bajo la GPL, entonces Red Hat está violando la GPL (aunque se ha argumentado que no es así; vea mi primer comentario arriba). La violación de la GPL implica que el software es de código abierto bajo la GPL. Choclei ( discusión ) 02:29, 14 de julio de 2023 (UTC) [ responder ]
- Una cosa de la que me acabo de dar cuenta es que RHEL tiene que ser de código abierto para que Red Hat viole su licencia, lo que creo que facilita las cosas. El hecho de que Red Hat cumpla o no con la GPL es irrelevante (si no lo hace, en realidad demuestra que RHEL es de código abierto). Por lo tanto, solo necesitamos una prueba de que RHEL está bajo una licencia de código abierto; no soy abogado, pero parece que sí, ya que el EULA de Red Hat otorga a los usuarios finales la GPL, que es una licencia de código abierto. (Por cierto, también permite explícitamente la redistribución siempre que se eliminen las marcas registradas, pero eso no es relevante, como dije anteriormente).
- (Además, @Chess . Te estoy enviando un ping ahora, porque olvidé hacerlo en mi comentario anterior. Lo siento por eso). Choclei ( discusión ) 02:25, 14 de julio de 2023 (UTC) [ responder ]
- El EULA que acabas de citar solo rige el uso de RHEL. La compra de licencias de RHEL se rige por el Enterprise Agreement. No soy abogado, pero después de un análisis rápido, parece que son las TOS las que prohíben lo que mencioné anteriormente. Además, RHEL no solo está bajo la GPL, muchos otros componentes están bajo otras licencias. Quetstar ( discusión ) 03:59, 14 de julio de 2023 (UTC) [ responder ]
- No encuentro los términos del servicio... Aaron Liu ( discusión ) 13:15 14 jul 2023 (UTC) [ responder ]
- Creo que encontré la sección en cuestión, está en este Apéndice en el Capítulo 1.2, párrafo G. Se trata del "Uso no autorizado de los Servicios de Suscripción" Quetstar ( discusión ) 14:20 14 jul 2023 (UTC) [ responder ]
- Gracias.
En ese caso, la situación se torna aún más sombría y viola aún más la GPL. O encontramos una fuente confiable que diga directamente que no es de código abierto, o simplemente deberíamos eliminar las menciones actuales no históricas. Aaron Liu ( discusión ) 14:32 14 jul 2023 (UTC) [ responder ] - Consulte la Sección 1.4 en ese mismo Apéndice, que dice explícitamente: 'Este Acuerdo establece los derechos y obligaciones asociados con los Servicios de suscripción y no pretende limitar sus derechos a
- código de software bajo los términos de una licencia de código abierto. Choclei ( discusión ) 16:56 14 jul 2023 (UTC) [ responder ]
- Vaya, me retracto de mis últimos comentarios. Aaron Liu ( discusión ) 17:07 14 jul 2023 (UTC) [ responder ]
- ¿Podrías citar las partes relevantes que encontraste en su Acuerdo Empresarial? Choclei ( discusión ) 16:54 14 jul 2023 (UTC) [ responder ]
- Se indica en la página principal.
Condiciones que rigen la
compra
y el uso de todos los productos y servicios de Red Hat.
Aaron Liu ( discusión ) 17:09 14 jul 2023 (UTC) [ responder ]
- Dado que está en cuestión, comenzaría por eliminar por completo cualquier referencia al código abierto y luego trabajaría con lo que digan las fuentes secundarias confiables. Si no hay ninguna, déjelo eliminado. SportingFlyer T · C 13:40, 14 de julio de 2023 (UTC) [ responder ]
- Creo que deberíamos etiquetar las actuales como "dudosas", añadir la controversia al artículo y dejar las referencias históricas en paz. Aaron Liu ( discusión ) 13:42 14 jul 2023 (UTC) [ responder ]
- El etiquetado implica que deberíamos tener una discusión en la página de discusión para resolver la etiqueta. El etiquetado de mantenimiento del artículo con Template:Dubious (o mejor aún Template:Disputed ) podría ser una buena idea antes de que se realice esta RFC, pero no es una solución a largo plazo. Chess ( discusión ) (por favor mencióname en la respuesta) 15:18, 14 de julio de 2023 (UTC) [ responder ]
- Necesitamos fuentes. Un artículo de noticias de Techcrunch sobre la bifurcación de RHEL por parte de SUSE dice: "Cuando Red Hat cambió la forma en que se desarrolla CentOS, de repente se volvió mucho más difícil para Rocky y Alma obtener acceso al código fuente de RHEL, que es de código abierto". Para contrarrestar esa referencia, necesitamos una fuente que diga que RHEL no es de código abierto. Si una fuente dice que RHEL está violando la GPL, solo demuestra que el software es GPL y de código abierto. Choclei ( discusión ) 17:30 14 jul 2023 (UTC) [ responder ]
- Aunque diría que GPL=código abierto es investigación original, especialmente cuando se dice que no se ajusta a ella, estoy de acuerdo con el resto. La responsabilidad recae en realidad sobre quienes afirman que no lo es. Aaron Liu ( discusión ) 17:32 14 jul 2023 (UTC) [ responder ]
- Sí, estoy de acuerdo con esto. Sin embargo, entiendo que si alguien redistribuye el código, que está bajo la GPL y otras licencias, Red Hat puede cancelar la suscripción de ese usuario por incumplir las condiciones de servicio y, por lo tanto, cortar su acceso al código, así como a cualquier actualización de RHEL. Quetstar ( discusión ) 23:52 14 jul 2023 (UTC) [ responder ]
- En primer lugar, la GPL no otorga a los usuarios el derecho a actualizaciones. Además, todo lo que has dicho siempre ha sido así. Los términos de servicio de RH no han cambiado y la GPL sigue vigente incluso si no tienes una suscripción. Lo único que ha cambiado es que el código fuente de RHEL ya no está disponible para todos, pero la GPL no dice que tenga que estarlo. Lo más importante es que fuentes fiables dicen que, a pesar de este cambio, RHEL sigue siendo técnicamente de código abierto.
- ¿Qué fuentes dicen que RHEL se ha vuelto "código fuente disponible"? Primero deberíamos recopilarlas y revisarlas, y luego llegar a un consenso sobre si deberíamos mantener la descripción de RHEL de software de código abierto. Choclei ( discusión ) 18:03, 15 de julio de 2023 (UTC) [ responder ]
- La SFC ha publicado este artículo que describe los posibles problemas de cumplimiento que conlleva este cambio. Quetstar ( discusión ) 19:38, 15 de julio de 2023 (UTC) [ responder ]
- Técnicamente, es una fuente primaria y tampoco dice explícitamente que no sea de código abierto. Aaron Liu ( discusión ) 00:12 16 jul 2023 (UTC) [ responder ]
- Gracias por eso. Parece que la SFC está tomando una postura contra Red Hat, pero el problema que tengo con ese artículo es que realmente no dicen si su modelo de negocios cumple o no con la GPL. Además, parece que están en desacuerdo con RH desde mucho antes de que comenzara toda esta controversia. Parecen decir que, independientemente de si estos cambios recientes cumplen con la GPL o no, este es solo uno de los muchos casos en los que Red Hat ha tomado decisiones que van en contra del espíritu del código abierto, cuando no violan abiertamente la GPL.
- Aquí hay algunas citas que considero relevantes para esta discusión.
Red Hat de IBM definitivamente merece crédito por construir tan cuidadosamente su modelo de negocios, de modo que ha pasado la mayor parte de las últimas dos décadas en el turbio territorio de “probablemente no violar la GPL”.
Tal vez el mayor problema con un modelo de negocios turbio que bordea la línea del cumplimiento de la GPL es que pueden ocurrir y ocurren violaciones, ya que incluso una desviación menor del modelo de negocios viola claramente los acuerdos de la GPL.
Dicho esto, el modelo de negocios tal como lo describe Red Hat de IBM puede muy bien cumplir con la GPL; es sólo que es tan turbio que cualquier ajuste al modelo en cualquier dirección parece definitivamente violarla, según nuestra experiencia.
En una situación normal, sin factores atenuantes, el hecho de que una empresa pasara de distribuir CCS públicamente a todo el mundo a dárselo sólo a los clientes que ya habían recibido los binarios no plantearía problemas. En esta situación, sin embargo, se completa lo que parece ser un plan de una década de Red Hat para maximizar el nivel de dificultad de aquellos en la comunidad que desean “confiar pero verificar” que RHEL cumple con los acuerdos de la GPL.
- También he encontrado un artículo de ZDNET en el que Bradley M. Kuhn, el autor del artículo de SFC, da más de su opinión sobre el tema. El artículo dice:
¿Viola Red Hat la licencia de propiedad intelectual (PI) básica de Linux, la Licencia Pública General GNU versión 2 (GPLv2)? Kuhn no irá tan lejos. Pero le preocupa que Red Hat haya "pasado de distribuir [el código fuente] públicamente a todo el mundo a dárselo sólo a los clientes que ya recibieron los binarios". En resumen, el "turbio modelo de negocio de Red Hat roza la línea del cumplimiento de la GPL".
Además, el autor del artículo de ZDNET (no Kuhn) dice: Tal como yo lo veo, Red Hat no está violando la letra de la GPLv2, pero sí su espíritu.
- Al final, no creo que esto sea suficiente para cambiar la descripción de RHEL de "código abierto" a "código fuente disponible", especialmente porque hay fuentes que dicen que es de código abierto pero ninguna que diga que es de código fuente disponible. Choclei ( discusión ) 00:19 16 jul 2023 (UTC) [ responder ]
- Pero, ¿"cumplir con la GPL" significa necesariamente "código abierto"? No creo que sea así, y ninguna de las fuentes lo dice. La mayor parte de esta discusión se centra en la suposición de que GPL = código abierto, pero Red Hat ha descubierto lo que fuentes confiables describen como una capacidad para violar el espíritu de la GPL. Chess ( discusión ) (por favor mencióname en la respuesta) 02:16 16 jul 2023 (UTC) [ responder ]
- @ Chess : Creo que sí. Wikipedia define el software de código abierto como
un software informático que se publica bajo una licencia en la que el titular de los derechos de autor concede a los usuarios el derecho a utilizar, estudiar, modificar y distribuir el software y su código fuente a cualquier persona y para cualquier propósito.
La GPL es una de esas licencias. - Además, Techcrunch dice explícitamente que RHEL es de código abierto. ¿Hay alguna fuente que diga que RHEL es de código abierto (o no de código abierto) porque viola el espíritu del código abierto, a pesar de cumplir con la GPL? Choclei ( discusión ) 04:44 16 jul 2023 (UTC) [ responder ]
- @Choclei: No solemos utilizar las definiciones de Wikipedia para resolver las solicitudes de adhesión, sino lo que dicen fuentes de terceros. Además, deberías incluir el enlace al artículo de TechCrunch que mencionas. Quetstar ( discusión ) 05:06 16 jul 2023 (UTC) [ responder ]
No solemos utilizar las definiciones de Wikipedia para resolver los RfC, sino lo que dicen fuentes de terceros.
¿Y qué dicen? ¿Dicen que uno está obligado a respetar el espíritu de la licencia incluso si cumple con ella? No parece que sea así.- Según las Preguntas frecuentes de la Iniciativa de Código Abierto,
la definición de código abierto reconocida internacionalmente proporciona diez criterios que deben cumplirse para que cualquier licencia de software y el software distribuido bajo esa licencia puedan ser etiquetados como “software de código abierto”. Solo el software licenciado bajo una licencia de código abierto aprobada por la OSI debe ser etiquetado como software de “código abierto”.
- Más adelante, en las preguntas frecuentes, puede encontrar lo siguiente:
¿<ALGÚN PROGRAMA> es de código abierto? Solo si utiliza una de las licencias aprobadas y publica el software adecuado.
El requisito parece ser bastante claro y simple, y parece que RHEL lo cumple. Además, deberías vincular el artículo de TechCrunch que mencionas.
- Es el artículo al que se hace referencia en mi comentario principal. Permítanme citar el artículo nuevamente:
Cuando Red Hat cambió la forma en que se desarrolla CentOS, de repente se volvió mucho más difícil para Rocky y Alma obtener acceso al código fuente de RHEL, que es de código abierto.
- En este punto, no creo que este RfC tenga mucho fundamento. Quiero decir, ¿qué más se necesita? Choclei ( discusión ) 09:20 16 jul 2023 (UTC) [ responder ]
- Entonces eres libre de ir a otro lado. Quetstar ( discusión ) 05:38 18 jul 2023 (UTC) [ responder ]
- ¿Qué se supone que significa eso? Aaron Liu ( discusión ) 13:14 18 jul 2023 (UTC) [ responder ]
- @Choclei dijo que esta RfC no tiene fundamento, por eso lo dije. Quetstar ( discusión ) 15:01 18 jul 2023 (UTC) [ responder ]
- Estoy bastante seguro de que quieren decir que el argumento de que la fuente está disponible no tiene fundamento. Aaron Liu ( discusión ) 15:32 18 jul 2023 (UTC) [ responder ]
- Propongo entonces que se cierre esta convocatoria. Quetstar ( discusión ) 21:36 19 jul 2023 (UTC) [ responder ]
- Deberíamos llegar a un consenso con @Chess primero Aaron Liu ( discusión ) 22:15 19 jul 2023 (UTC) [ responder ]
- Me han convencido. No me gusta, pero eso es lo que dicen las fuentes. Ajedrez ( discusión ) (por favor, mencióname en la respuesta) 01:47 21 jul 2023 (UTC) [ responder ]
- Re: a TechCrunch, disculpas, me lo perdí. Ajedrez ( discusión ) (por favor, mencióname en la respuesta) 15:53 16 jul 2023 (UTC) [ responder ]
La discusión anterior está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.
Referencias
- ^ "Mantener abierto el código abierto". rockylinux.org . Consultado el 29 de junio de 2023 .