También puedo usar el modo seguro para tener una idea de los cambios que han realizado otras distribuciones de Discourse:
Purism solo tiene un par de scripts de temas (que podrían ser parte del Discourse oficial, ya que el modo seguro bloquea todos los temas, creo) y una pieza interna (es decir, parte del archivo HTML, no un archivo JS externo) de JavaScript, que comienza con const DELAY_TARGET=2e3,POLLING_INTERVAL=50,splashS…
Exercism tiene lo que parece ser el plugin discourse-spoiler-alert que se agregó más tarde al núcleo, así como el mismo JS interno que Purism.
El foro de miembros de FSF tiene solo ese mismo JS interno que los otros dos.
Discourse Meta (este foro) parece tener muchas diferencias en JS.
discourse-activity-pub
discourse-customer-flair-plugin (no pude encontrar una licencia para este en ningún lado)
discourse-deprecation-collector
discourse-doc-categories
discourse-new-features-feeds (tampoco se encontró licencia para este)
muchos más scripts, incluidos algunos que ni siquiera tienen un enlace a un mapa de origen.
Así que parece que la mayoría de las distribuciones de terceros (basado en mi pequeña muestra de 3) se mantienen bastante cerca del Discourse principal, pero esto hace que parezca que esta distribución contiene plugins que no formarían parte de la mayoría de las distribuciones. ¿Sabes dónde encontraría el código fuente con licencia para todos esos? ¿Estarían en el repositorio principal? No pude encontrarlos buscando algunos de esos nombres en el repositorio principal, pero es posible que me lo haya perdido.
Intenté buscar en todo el foro “discourse-new-features-feeds” (por ejemplo) y no encontré nada. Para algunas extensiones, pude encontrarlas en el directorio de plugins, en GitHub o aquí en los foros, pero para discourse-new-features-feeds y discourse-customer-flair-plugin, no pude encontrar nada. No revisé cada script de plugin, así que puede haber más que no podría encontrar.
Supongo que puede haber una razón por la que, por ejemplo, las personalizaciones de Meta no son públicas. O no profundizaste lo suficiente en el repositorio de Discourse
Es posible que sean un cliente de Enterprise y hayan hecho que Discourse personalice especialmente su foro para ellos.
Además, si quieres usar el modo seguro para ver personalizaciones del lado del cliente, ¿no lo deshabilitaría en lugar de eso? ¿Cómo lo habilitarías en estos sitios en primer lugar?
Por curiosidad, me pregunto cuál es exactamente toda la lógica aquí. Simplemente no puedes navegar por internet con las preocupaciones que planteas, ¿correcto?
Hablas de “licencia”. Pero tu propia licencia para usar un foro específico como un simple usuario sería diferente de la licencia para ejecutar realmente el software del foro (= si alguien quiere configurar otro foro con él). ¿Por qué le importaría a un usuario lo último? ¿Debido a algunos principios a los que quiere adherirse? Supongo que cualquier personalización no redistribuida sería “propietaria”. Lo que plantea la pregunta de dónde empieza y dónde termina.
Puedes desconfiar de javascript y de lo que podría permitir ejecutar en tu navegador (los riesgos y las posibilidades de eso a menudo se debaten. Se supone que está limitado). No estoy seguro de si Discourse puede ejecutarse sin él, o ejecutarse correctamente, al menos. Siempre puedes intentarlo. Existe la popular extensión de navegador “NoScript” para eso, por ejemplo.
Todavía me pregunto sobre el razonamiento: ¿Se trata de código malicioso potencial? En este caso, no tendría mucho sentido para mí que te sintieras mejor con una licencia que DICE que un foro ejecuta una versión no modificada. ¿O de qué se trata?
En general, quiero evitar ejecutar software no libre. La razón principal es que creo que debo tener control sobre el software que se ejecuta en mi computadora, y una razón adicional es que no me gusta la idea de errores que pueden ser ilegales de corregir. También creo que sería bueno si obtuviera mi software de un número reducido de repositorios confiables, en lugar de descargar software de cientos de sitios web independientes diferentes sin supervisión ni rendición de cuentas de terceros, por lo que es importante para mí poder empaquetar el software que uso para un repositorio en el que confío (aunque esto es bastante poco práctico para JavaScript servido por el sitio con la tecnología actual).
No creo que deba tener control sobre el software que se ejecuta en las computadoras de otros, porque creo que el operador del servidor debería tener ese control, y no me parece sensato que varios usuarios tengan control total sobre el software.
No, es relativamente fácil evitar ejecutar software no libre en Internet si no usas programas que descargan y ejecutan automáticamente código arbitrario de terceros no confiables, o si modificas dichos programas para que no lo hagan (por ejemplo, instalando LibreJS en tu navegador web).
Por lo que puedo decir, ejecutar el software del foro es necesario para usar la mayoría de las funciones del foro, aunque leer las publicaciones funciona sin él. Si quiero registrar una cuenta y publicar temas, parece que tengo que ejecutar el software del foro. La mayoría de la gente no se da cuenta porque la mayoría de los navegadores descargarán y ejecutarán cualquier software que el sitio web envíe, sin notificar al usuario.
Parte del software del foro se ejecuta en el servidor, y entonces las instancias de Discourse no necesariamente distribuirán ese software en absoluto, lo que significa que ni siquiera obtendría necesariamente ningún software no libre que la instancia haya agregado al lado del servidor, por lo que no intento evitar las instancias que hacen esto.
aparte sobre definiciones
En mi opinión, el software que nunca se distribuye es “propietario” porque tiene un único “propietario” (el autor), pero también es “libre” porque todos sus usuarios (solo uno, el autor) son libres de hacer lo que quieran con él. Bueno, supongo que se podría decir que las personas que interactúan con un servidor son “usuarios” del software en ese servidor, así que tal vez debería usar una palabra diferente a “usuarios”, pero no estoy seguro de qué palabra usar en su lugar. Tal vez técnicamente soy un “usuario” del software que se ejecuta en la red telefónica o en el teléfono de otra persona si llamo a alguien.
Sí, tengo NoScript instalado, y cuando bloqueo el software de Discourse del lado del cliente, por supuesto que Discourse no puede “ejecutarse” sin él, porque he evitado que el navegador ejecute los scripts. El software del lado del servidor, que no se ejecuta en mi computadora, no es bloqueado por NoScript. En este estado, los temas y comentarios servidos por el software del servidor Discourse son visibles, pero para registrarse y publicar parece que necesitas usar el software JavaScript del lado del cliente.
Con respecto al malware, si un programa de software libre es malware, entonces alguien puede modificarlo para que no sea malware y luego distribuir esa versión modificada para usarla en su lugar. Para JavaScript servido por el sitio, esto es actualmente algo poco práctico. Idealmente, habría una licencia que estableciera directamente que el software es software libre, de modo que incluso si el software se modificara, seguiría siendo legal usarlo como software libre. Tal como están las cosas, tengo que confiar en que las distribuciones que uso no “mienten” sobre qué versión del software están utilizando (por ejemplo, modificando el software del servidor Discourse para afirmar que se está utilizando un commit cuando en realidad es otro).
Probablemente hice esta respuesta un poco larga, pero el núcleo es que valoro la libertad del software y, por lo tanto, quiero evitar ejecutar software no libre en mi computadora.
En este caso, “ellos” es Discourse Meta. ¿No es eso parte de Discourse (la empresa)?
Sí, lo que quise decir fue: con el modo seguro puedo deshabilitar los scripts de las modificaciones y luego comparar qué software se envía al navegador en ambos casos. La diferencia son las modificaciones y los temas.
El modo seguro se puede habilitar navegando a /safe-mode (por ejemplo, http://meta.discourse.com/safe-mode) y seleccionando las opciones allí. Esa página no requiere JavaScript, por lo que el modo seguro se puede habilitar mientras se usan extensiones como NoScript, LibreJS y/o Haketilo para bloquear el JS o estableciendo javascript.enabled en false en la configuración del navegador para navegadores basados en Firefox.
En este punto, puedes comparar las etiquetas de script en ambas páginas para ver qué se eliminó con el modo seguro. Usé un script como este:
script-diff.js
// SPDX-FileCopyrightText: 2024 Jacob K
//
// SPDX-License-Identifier: CC0-1.0
// en la página con más scripts
const scriptSrcArr = [];
for (script of document.scripts) {
if (script.src) {
scriptSrcArr.push(script.src);
} else {
scriptSrcArr.push(script.textContent);
}
}
console.log(scriptSrcArr)
// en la página con menos scripts (Necesitarás hacer clic derecho en la matriz y hacer clic en "Copiar Objeto" en la primera página)
scriptSrcArr = PEGAR_OBJETO_DE_LA_OTRA_PÁGINA_AQUÍ
for (script of document.scripts) {
if (!scriptSrcArr.includes(script.src)) {
console.info(script)
}
}
// Asumo que los scripts en la primera página son un superconjunto de los scripts en la segunda página
@Jagster (intentando responder mediante edición, como sugirió Discourse (¡genial función de sugerencias!))
Eso me hace pensar que Discourse, tal como lo distribuye meta.discourse.org, es software no libre, lo que significaría que las afirmaciones de “Todo el código de Discourse es abierto y está libremente disponible para el público” y “Discourse es 100% gratuito, código abierto software de foro.” (ambos de www.discourse.org) parecen engañosas, incluso si técnicamente es cierto porque el software no es lo mismo que sus complementos. Me siento un poco como si me hubieran engañado para ejecutar software no libre
Supongo que esa afirmación está realmente destinada a personas que tienen la intención de alojar instancias de Discourse, no a unirse a las existentes.
Espero estar equivocado y que realmente sea el caso de que simplemente no miré lo suficientemente de cerca el repositorio.
Debes sentir eso muy a menudo. Sin emoticonos, porque solo fue una declaración debido a cómo funciona internet y las aplicaciones en él.
Acabas de decir que las personalizaciones son malas, y si la base es de código abierto, entonces todos los complementos también deben ser gratuitos. Bueno, creo que WordPress usó eso, pero ciertamente no con wordpress.com, pero si visitas mi sitio de WordPress, hay mucho trabajo personalizado. Algunos son propietarios, otros son abiertos, otros son personalizados y otros son míos. Y no en esta realidad sucederán dos cosas:
todo el código del trabajo personalizado sería público
Te diría a ti o a cualquier visitante si tengo o no una licencia válida
Pero me cuesta entender por qué Discourse, WordPress, Moodle, etc. no serían gratuitos si algunos complementos no son gratuitos. No entiendo la lógica detrás de ese pensamiento.
Ese es definitivamente el punto
No se puede predecir en qué podrían adaptarlo los anfitriones.
De hecho, además y, por ejemplo, a discreción del anfitrión, pueden añadir:
publicidad
suscripciones
Y si bien el “software” puede seguir siendo “de uso gratuito”, algunas funciones podrían estar restringidas y la publicidad solo se desactivaría para los suscriptores de pago.
No todo el mundo tiene fondos ilimitados para ejecutar una instancia de Discourse de forma gratuita. Muchos sitios necesitan generar ingresos para pagar sus facturas.
Ejecutar un Discourse nunca es “gratuito” a escala. El anfitrión tiene que pagar los costos del nombre de dominio, VPS y servicios de correo electrónico, por nombrar los principales.
(… ¡y no entremos en los costos de desarrollo de Discourse en primer lugar!)
Los administradores de su propio sitio de Discourse tienen la libertad de personalizar su propio foro. Los plugins, temas y TCs no siempre tienen que ser de código abierto. Discourse está de acuerdo con eso, ya que hay formas de usar repositorios privados en lugar de públicos para conectar estas personalizaciones.
Lo mismo ocurre con cualquiera de los plugins, excepto en ocasiones muy, muy, muy raras (¡quizás incluso casi nunca!) estas personalizaciones serán de pago [1]. Así que nada es “no libre”: todo es libre.
Mi punto es que el software de código abierto será libre. Los plugins son gratuitos, es tu elección usarlos. Lo mismo ocurre con los temas, TCs, etc. Lo que no es de código abierto, sin embargo, puede ser de pago, pero los administradores eligieron hacerlo gratuito. No hay nadie que te impida, si quieres, hacer una copia de una personalización de código cerrado lo mejor que puedas y usarla tú mismo.
Discourse es gratuito, sus personalizaciones públicas [2] son gratuitas, sus personalizaciones privadas también son gratuitas de usar (al menos en muchos lugares, pero
. Pagarle al propietario por el código fuente es otra cosa, sin embargo.
Esencialmente, a menos que crees un plugin/tema/TC tú mismo y no lo compartas, siempre puedes instalar personalizaciones de forma gratuita. Nadie te lo impide.
Lamento si esto suena grosero o cortante, o si doy vueltas y repito lo mismo.
Excepto por encargos de pago, que es tu propia elección patrocinarlo. ↩︎
es decir, las que se enumeran aquí en Meta o en GitHub públicamente ↩︎
Eso no es necesariamente cierto. De nuevo: se trata de libre como en libertad, no como en precio. Hay proyectos de código abierto que tienen licencias que son demasiado restrictivas para ser consideradas software libre según la definición de la FSF. Ejemplos son MongoDB y ElasticSearch.
Ejecutar software libre no implica que tengas control sobre él.
Así que parece que estás mezclando ‘confiable’ y ‘libre’. Cuando un administrador de servidor compila Discourse, el proceso de compilación descarga todo tipo de paquetes de NPM. ¿Se puede confiar siempre en ellos? (La historia nos ha enseñado que este no es el caso - ejemplo y otro).
¿“Supongo” Un administrador de servidor puede hacer modificaciones sin cambiar el hash del commit. Y un plugin también puede inyectar código Javascript.
Lamento decirte que eso no es cierto.
Esto no se trata de libre o no libre o de código abierto o cerrado, sino de confianza.
Si visitas una instancia de Discourse, tendrás que confiar en
el(los) administrador(es) del servidor
todos los que tengan acceso de commit en la organización de Discourse de GitHub
todos los que tengan acceso de commit en los repositorios de plugins
todos en GitHub
toda la cadena de software de NPM
todos los que tengan acceso de commit a cualquier repositorio de NPM que se esté utilizando
todos los que tengan control sobre el software de tu navegador
la empresa que proporcionó el certificado SSL y la cadena de confianza
¿Lo que serán al menos unas pocas miles de personas?
Los plugins y componentes de temas se pueden encontrar en repositorios separados.
No todos los plugins son de código abierto (por ejemplo, discourse-customer-flair-plugin no lo es, que yo sepa). Así que ahí lo tienes. Tendrás que dejar de usar Meta Es broma, por supuesto. Mi punto es que puede haber suficiente confianza sin que todo sea de código abierto o libre.
Solo algo, @JacobK1, ¿has leído la licencia de Discourse?
Citando algunos puntos que pueden ser relevantes:
la Licencia Pública General de GNU
pretende garantizar su libertad para compartir y modificar software libre, para asegurar que el software sea libre para todos sus usuarios.
Puede modificar su copia o copias del Programa o cualquier porción
del mismo, formando así una obra basada en el Programa, y copiar y
distribuir dichas modificaciones u obra bajo los términos de la Sección 1
anterior
Espero que esto haya sido respondido arriba y en la cita anterior a esta.
Si entiendo correctamente, todo esto está principalmente vinculado a javascript. Y se trata de lo que se ejecuta con javascript dentro de tu navegador, que es servido por cada instancia de Discourse. También se trataría principalmente de “confianza” y de tener la capacidad de saber qué código se ejecuta (poder echarle un vistazo). ¿Correcto?
Esto está bastante por encima de mis capacidades, pero ¿puedes tener “control” sobre esto? A menos que estuvieras enviando un commit que cambiara las cosas para todos, no creo que pudieras “arreglarte” realmente nada aquí, ya que lo que llamas el “software” que se ejecuta en tu computadora te lo proporciona el servidor a tu navegador cada vez.
Incluso si cada foro publicara su propio código de código abierto, con todas las modificaciones posibles, ¿puedes saber con certeza que eso es lo que realmente están ejecutando en todo momento? No es como si pudieras descargarlo una vez, revisarlo y compilarlo tú mismo en tu extremo.
Lo que realmente querrías es:
Sin javascript (no hay suerte con Discourse en ese aspecto, ya que depende bastante de él) o
Un cliente independiente de código abierto realmente instalado en tu computadora. Este último tampoco necesitaría usar javascript, si todo esto es posible con Discourse, lo cual no sé. Entonces podrías modificar tu cliente y tener el control sobre él que buscas.
¿Sería esa una comprensión justa?
(PD: También está por encima de mis capacidades, pero si mal no recuerdo, no el 100% del código de Discourse es de código abierto. Ahora, en realidad solo te importa lo que se ejecuta en tu extremo, no todo lo del lado del servidor)
Because I get the vast majority of my software using apt install instead of a web browser, and I trust my software distribution (Trisquel) to only distribute free software, this isn’t usually a concern.
Just to be clear, I am not saying customizations are necessarily bad, just that they may be bad if they are nonfree, so a way to be sure you avoid running nonfree software is to disable customizations.
To be clear, I am not trying to say Discourse is nonfree. It’s only this particular distribution of Discourse (Discourse Meta) that appears to include nonfree software.
I should have mentioned in my previous post that another reason I thought this distribution would be free is that the about page for Discourse says " There is only one version of Discourse – the awesome open source version.". This is, again, technically true because the plugins are not part of Discourse, but it felt misleading to me.
Discourse might not have control over third party distributions, but I would have expected Discourse instances hosted by Discourse to be free software if they are saying what they say on the about page. I might have also expected a license and/or framework that would effectively require derivatives to be free software, which there kind of is, since Discourse is GPL, but I guess it doesn’t cover plugins.
I think charging money for software or services is fine; usually the “free” in “free software” means “libre”, as in you are free to do what you want with it (copy, modify, etc.), after you get it. It does not necessarily mean that it is “free” as in “gratis” i.e. zero cost.
Strictly speaking, yes, there is no one stopping me, but it would be illegal, which seems bad. For private use this might work out, but generally public software repos and app stores don’t want to include code illegally, and some people who I might want to use the software may be uncomfortable running illegally copied code. I’m not sure I have the right approach; maybe I should just totally ignore copyright, but that seems like not the best option when it’s feasible to avoid illegal and nonfree software.
No worries! I don’t think you’re being rude, and I don’t yet feel like we’re going in circles.
What do you mean by this? If the software is free that means I can modify it; therefore I do have control over what it does.
I don’t think free is the same as trusted; perhaps I should have said “arbitrary” instead of “untrusted”, but my point was that most browsers will execute whatever code a webpage gives them, and since I often visit websites I have never visited before, many websites I visit are “untrusted”. For these websites, I have no reason to think they will not send nonfree software.
Regarding NPM, I consider it more trusted than an arbitrary website, but maybe not as trusted as my apt or guix repos. Though, trust is not one-dimensional; although I would not trust a new package on NPM just because it is on NPM, I would trust that when I download JQuery from NPM it really is JQuery. NPM may make mistakes that allow an attacker to replace JQuery, but NPM could take measures to avoid malware that would not be as realistic for site-served JavaScript (e.g. pre-publish automated/manual review, post-publish crowd-sourced review, automated checking that minified/obfuscated scripts match source code, rules against downloading and running arbitrary code at runtime). Importantly, when malware is found on NPM, there’s a third party (NPM, as opposed to the software developer) to report it to so it can be removed. This is not the case for site-served JavaScript - the only one who can remove it is the site operator.
Does that mean the listed commit hash would be incorrect if a server administrator made modifications and didn’t also change the listed commit hash? I thought updating software would change the commit hash automatically, and I (incorrectly?) assumed the listed commit hash would be updated automatically.
Would plugin-injected JavaScript be disabled with safe_mode=no_themes,no_unofficial_plugins?
So, would the only way to avoid nonfree software while using Discourse be to package a Discourse client as a browser extension or Haketilo package or something similar?
I’m not sure what you mean by that considering my original question is about software freedom, and not trust.
I disagree that everyone you listed has to be trusted.
The server administrators would not have to be trusted if you don’t run software served by them, for example if you get the Discourse client from GitHub and package it so it can be used with that server.
In many cases, people collaborating on software might read some of each others’ commits, so I don’t have to trust all authors individually.
So that would mean the Discourse Meta client is proprietary software, right? Though, it is possible to use safe mode to disable the plugin JS.
Maybe, but that’s not very helpful if I want to avoid nonfree software.
@NateDhaliwal
I have read the license in the Discourse git repo, but (because of the CLA) it does not necessarily apply to derivatives of Discourse outside of that repo. I would like to see a notice on every Discourse distribution that says which of the distributed software is libre. It would even (IMO) fit with the spirit of the GPL: “you must show them these terms so they know their rights”.
Yes, it is possible, to run JavaScript from a browser extension or proxy, such a Haketilo or GreaseMonkey, though this can be very impractical for some software, for example if it updates very often, as would be the case for software where data is baked into the JavaScript software. Haketilo also doesn’t have support for some kinds of scripts, for example scripts with a type of “module”.
Yes, I think your understanding is correct overall. Though packaging the JavaScript as a browser extension or for Haketilo or GreaseMonkey would effectively result in an independent installed client, even though it would be using JavaScript.
Todo lo que forma parte del producto principal que alojamos (incluido Meta), con la excepción que señalé anteriormente, es gratuito y de código abierto.
Algunos plugins dependen de plataformas propietarias para funcionar, pero eso no tiene nada que ver con que Discourse sea o no de código abierto.
Todas las instancias de Discourse alojadas por CDCK o por nosotros (soy cofundador de una empresa que aloja Discourse) están ejecutando uno o varios plugins de código cerrado para proporcionar cierta funcionalidad específica del entorno de alojamiento.
Creo que hay mucha confusión entre una distribución en el buen sentido clásico (aquí tienes un repositorio de GitHub y siéntete libre de hacer lo que quieras) y una distribución en el sentido más moderno (aquí tienes un sitio web y envía JavaScript a tu navegador). Además, hay confusión entre Discourse https://github.com/discourse/discourse y Discourse y todos sus plugins y componentes temáticos de terceros añadidos por los administradores del sitio.
Es un hash de commit, por lo que si se realizan modificaciones después de extraerlo del repositorio y antes de confirmarlo, ya tienes tal situación. Eso no necesita ser un acto malicioso, también sucederá si se aplican parches de seguridad (que normalmente se hacen antes de confirmarlos en una rama pública). Ahora, en general, los parches de seguridad no son del lado del cliente, pero podrían introducir algún código actualizado del lado del cliente.
Sí, al menos en teoría. No estoy seguro de lo difícil que es eludir eso (deliberada o accidentalmente).
¿Hay un repositorio separado con una licencia para los plugins que no encontré antes, como discourse-customer-flair-plugin? El JavaScript que se sirve al navegador tiene un enlace a un mapa de origen pero ninguna licencia, hasta donde puedo decir.
Mi entendimiento de “código de alojamiento/infraestructura” no incluiría JavaScript del lado del cliente; ¿es eso correcto?
Estoy de acuerdo. Creo que estoy confundido sobre a qué se aplica realmente la palabra “Discourse”.
Ah, de acuerdo, así que supongo que no habría una buena manera de saberlo.
Buen punto, alguien podría intentar ocultar una falla como esta. Pero parece más fácil mitigar ese problema auditando código de terceros que confiando en cada persona que alguna vez modificó el código original, aunque probablemente ninguno de los enfoques sería completamente práctico.
Sí, aunque es posible que la mayoría de las actualizaciones se puedan manejar automáticamente.
Supongo que eso es mayormente cierto en este caso.
Solo para tu información, @JacobK1: Bien hecho con Discourse, no es necesario etiquetar a alguien cuando citas a esa persona. La cita en sí ya generará una notificación (también era para crear subsecciones, hay que admitirlo )
Un administrador de servidor puede hacer modificaciones sin cambiar el hash del commit. Y un plugin también puede inyectar código Javascript.
Es broma, por supuesto. Mi punto es que puede haber suficiente confianza sin que todo sea de código abierto o libre.
)