forums, mailing lists and other tools

[Adonay Felipe Nogueira]

I see this JS issue as somewhat more problematic than it is, perhaps
because I'm too much in the website visitor/guest side? :D

These are the notes I have taken so far on the subject:

1. most web developers nowadays don't have stablished a standard as to
   how to display copyright and license notices in the JS *files* (.js)
   that are executed client-side. If they do have such, it's not machine
   readable, nor understandable by non-tech humans (because the notices
   will be too short, shorter than what the license actually recommends
   for the sake of the understandable;

2. most overlook the fact that their HTML (.html) pages might possibly
   have in-page JS through DOM/HTML event handlers, so the entire HTML
   file would be licensed accordingly.

3. Under the W3C HTML specification ([2]) and the ECMAScript
   specification ([3]), there is *no requirement* for the web
   browser/user-agent to offer, instead of blindlessly executing the
   code:

   - immediate display of copyright and license information for the
     end-user;

   - a warning of non-free software if the previous information is
     absent due to lazyness of the website owner;

   - button to download complete corresponding source;

   - button to black list the software;

   - button to white list the software;

   - a repetition/loop of the previous items for every JavaScript
     code/script that appears in a given page, including when there is
     an update in the script.

   The W3C HTML specification does describe the expected way a
   user-agent should behave, but it doesn't include anything related to
   the functions described in the previous unnumbered items (see [2]
   again).

4. GNU LibreJS (and its documentation, third-party guides, and also the
   mailing list) exist to try to stablish a standard on how to improve
   (2), but traditional proprietors simply get annoyed for no reason
   instead of trying to understand it and help make it better;

5. I'm still waiting for the resolution of an issue in one of FSFEs
   repositories ([1]) and also on the result of an improvement (with
   patches) that I sent privately to some other organization (which also
   has a legal team) which has an important campaign website with some
   licensing issues (even involving license compatibility), to reach
   back to me and tell what was decided. But as far as I have studied,
   MIT --- truly, either Expat or X11 licenses, and although MIT never
   made a license, historically they used various ones, and some are
   non-free, this is not the case for Expat nor for X11 ---, BSD ---
   considering only the free ones for simplicity --- and
   lax/permissive/non-copyleft licenses might require the full license
   to be keep as the license notice, thus making their notices longer
   than GPL-and-variants (even if one considers that at least in the
   latest version of GPL-and-variants, they have an exception that you
   can declare/use in the notice to not be obligated to transfer a full
   copy of the license to the site guest/visitor, whereas other licenses
   don't have such shortcut).

   Continuing the previous paragraph, it must be noted that it's still
   under pending status both in FSFE issue tracker and in the other
   organization's campaign website, so the issue isn't confirmed yet. I
   described the situation and study to Jason "jxself" Self in #peers at
   chat.freenode.net IRC, and he made an addendum describing that he
   thinks that the issue is non-existing since under a (hopefully not
   needed) judgement, the judge can use the argument of estoppel to have
   the lazy copyright holder (the one which uses shorter-than-required
   notices such as "Licensed under SomeLicense") to comply with the
   license used regardless. However, while this "Licensed under
   SomeLicense" would be legally valid, it still doesn't tell anything
   of understandable to the site visitor/guest.

6. Thanks to the existance of Meltdown/Spectre vulnerabilities --- which
   impact Intel, AMD, ARM and every processor with speculative execution
   enabled --- sandboxed JS execution might not be enough to protect the
   visitor/guest from attackers attempting to access private
   information. And while today a given JS can be trusted by the
   visitor/guest for a given website, the possibility of an intruder to
   make some change in the script's source and it being automatically
   accepted by the visitor/guest makes the situation worse.

Depending on how the Discourse project does provide their
visitor/guest/user-facing JS, then these items might have to be taken
into account. Considering only client-side safety, item (6) is an issue
as long as the page is allowed to have client-side JS.

[1] <https://git.fsfe.org/pmpc/website/issues/194>.

[2]
<https://www.w3.org/TR/html/semantics-scripting.html#semantics-scripting>.

[3] <https://www.ecma-international.org/ecma-262/8.0/index.html>.

2018-01-18T10:13:03+0100 Mirko Boehm wrote:
> Hello there!
>
> +1 for investigating Discourse. It was reviewed at the recent community
> meeting in Berlin and excitement was great. I agree with Daniel's concerns,
> and feel that the way Discourse works can help allay them. Especially the
> bridging of the traditional mailing list mode with a forum web interface can
> help making our discussions accessible to a wider range of people. The
> client-side Javascript to me is not a relevant issue anymore since JS is an
> open standard and browsers are sandboxed these days.
>
> Best,
>
> Mirko.