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.