electron again

The problem are people against "everything chromium", who claim without the slightest evidence that Electron is nonfree. If the Free Software Directory says it is free, then I believe it is: people editing that directory tend to do a good job.

That said, for the same reason, I believe the Parabola project if it claims that Electron *recommends* nonfree modules. It is a problem. But that does not make Electron itself nonfree.

are you sure about that? - cause i dont see it
https://directory.fsf.org/wiki/Electron

My bad. You are right: https://directory.fsf.org/wiki?title=Electron&oldid=71699 is an "unapproved revision".

the default copy and re-distribution permissions for every copyrighted work is "none" - if the authors of some work want that work be be set free, they must very explicitly label it as such, and try their very best to ensure that their formal statement of permission follows along with any copies of it - if that permission is missing, or is difficult to locate or comprehend, then there it is not reasonable to assume that the work is freely distributable

That permission is here: https://raw.githubusercontent.com/electron/electron/master/LICENSE

A couple of sub-directories include Chromium's main license, which is as permissive:

• https://raw.githubusercontent.com/electron/electron/master/chromium_src/LICENSE.chromium
• https://raw.githubusercontent.com/electron/electron/master/native_mate/LICENSE.chromium

regarding electron specifically, its chromium heritage seems to be the least of its problems - for anyone who thinks electron is freely distributable, i had a very enlightening discussion with a fedora dev a while ago that may be of interest; in which he explained to me why fedora's review of electron ended with it being unanimously rejected for inclusion
https://lists.gnu.org/archive/html/directory-discuss/2017-12/msg00008.html

I read your email several times. I fail to understand the problem. I understand Electron's developers suggest to rely on prebuilt binaries rather than compiling everything from source, what takes "a very, very long time for the build to complete" (quote behind the first link you give). That is a convenience. But those same developers give what looks like precise instructions to compile from source (your second link). You even write:

If you build libchromiumcontent from source, then Electron from source based on that, then the apps from source based on that, THEN you can distribute this in a distro, assuming the Chromium licensing issue is addressed.

Well, it is more "assuming the parts of Chromium that ended up in Electron are not among those raising licensing issues". It does not look like it is the case (based on my rather comprehensive look at https://github.com/wireapp/wire-desktop/tree/master/electron ... which is not upstream Electron though).

he was implying that one MUST build it from source, and he was not aware of anyone who even tried doing so - therefore practically speaking, the electron "apps" that exist are most probably not legit;

That sounds like "building from source, although documented, looks hard; let us just say Electron is nonfree and have an excuse to not do it".

If Electron could not be successfully built from source, then it would be proprietary. But if noone has "even tried doing so", then that conclusion cannot be reached.

simply slapping a LICENSE file on top of a pile of collected sources, does not necessarily put the entire program under that license - the task of determining the licensing status of a program that large, is much more complex than that - chromimum is not a single project written by one team - it is a collection of many distinct projects, previously written by many teams, some almost surely containing files from yet other projects - in order for the entire aggregate program to be freely distributable, all files that were not written by a member of the aggregate program's team must have been freely licensed by their respective authors prior, the various licenses those authors chose need to be verifiable, and all the individual licenses of every file in the program must not conflict with each other

I am very well aware of that. See some problems I easily found in Chromium's source: https://trisquel.info/forum/free-software-foundations-problems#comment-128239 (observation: Electron's source does not have a "third_party" sub-directory).

if there is even one source file that is GPL licensed, for example, the entire program could only be distributed under the GPL, regardless of the contributions made under other licenses, including the one sitting at the top level

I am aware of that too. But shouldn't you point out such a source file? I searched for "GNU" or "GPL" in Electron's source:
$ git clone https://github.com/electron/electron
(...)
$ grep -Re GNU -e GPL electron/*
electron/build/args/release.gn:# who have an LGPL requirement to ship ffmpeg as a dynamically linked library,
electron/patches/common/boringssl/add_ec_group_order_bits_for_openssl_compatibility.patch:@@ -625,6 +625,10 @@ int EC_GROUP_get_order(const EC_GROUP *group, BIGNUM *order, BN_CTX *ctx) {
electron/patches/common/boringssl/add_ec_group_order_bits_for_openssl_compatibility.patch: int EC_GROUP_get_cofactor(const EC_GROUP *group, BIGNUM *cofactor,
electron/patches/common/boringssl/add_ec_group_order_bits_for_openssl_compatibility.patch: OPENSSL_EXPORT const BIGNUM *EC_GROUP_get0_order(const EC_GROUP *group);
electron/patches/common/boringssl/add_ec_key_key2buf_for_openssl_compatibility.patch: BIGNUM *x,
electron/patches/common/boringssl/add_ec_key_key2buf_for_openssl_compatibility.patch: BIGNUM *y);
electron/patches/mips64el/chromium/backport-sqlite-3d8ec48.patch: // only defines mremap if _GNU_SOURCE is defined. Depending on the order of the
electron/patches/mips64el/chromium/backport-sqlite-3d8ec48.patch: #if defined(__GNUC__) && !defined(_GNU_SOURCE)
electron/patches/mips64el/chromium/backport-sqlite-3d8ec48.patch:-# define _GNU_SOURCE
electron/patches/mips64el/chromium/backport-sqlite-3d8ec48.patch:+#define _GNU_SOURCE
electron/patches/mips64el/chromium/backport-sqlite-8a87f7e.patch:+ $GNU_SED --in-place 's/[[:space:]]\+$//' {} \+
electron/patches/mips64el/chromium/backport-sqlite-8a87f7e.patch:- $GNU_SED --in-place 's/[[:space:]]\+$//' {} \+
electron/patches/mips64el/chromium/backport-sqlite-8a87f7e.patch:-# Generated by GNU Autoconf 2.69 for sqlite 3.20.0.
electron/patches/mips64el/chromium/backport-sqlite-8a87f7e.patch:+# Generated by GNU Autoconf 2.69 for sqlite 3.21.0.
electron/patches/mips64el/chromium/backport-sqlite-8a87f7e.patch: generated by GNU Autoconf 2.69
electron/patches/mips64el/chromium/backport-sqlite-8a87f7e.patch: generated by GNU Autoconf 2.69. Invocation command line was
electron/patches/mips64el/chromium/backport-sqlite-8a87f7e.patch: generated by GNU Autoconf 2.69. Invocation command line was
electron/patches/mips64el/chromium/backport-sqlite-8a87f7e.patch: configured by $0, generated by GNU Autoconf 2.69,
electron/patches/mips64el/chromium/backport-sqlite-8a87f7e.patch:+#if defined(__GNUC__)
electron/patches/mips64el/chromium/backport-sqlite-8a87f7e.patch:+#if __GNUC__ && (defined(__i386__) || defined(__x86_64__))

The first match relates to a comment allowing, by modifying a variable, to (or to not) ship proprietary codecs. The remaining matches are irrelevant. Sure, the developers could have taken GPL code after stripping out the license notice. Or GPL code could be in Chromium's pieces that would be downloaded while building (what would contradict what you wrote earlier: "regarding electron specifically, its chromium heritage seems to be the least of its problems - for anyone who thinks electron is freely distributable"). Or in other pieces (notice https://github.com/electron/libchromiumcontent that explains that "as of Electron 4.0.0, libchromiumcontent is no longer built separately from Electron").

Nevertheless, if the licenses are not considered enough, then that means violations are assumed. In those conditions, how does https://directory.fsf.org/wiki/Free_Software_Directory:Free_software_evaluation expect Electron's developers to prove that "their code is 100% freely distributable"? Should they swear they have not violated any license?

So, again, I consider the burden of the proof is on those who claim Electron is nonfree. I perfectly understand that Electron's source and building process deserves more scrutiny, given the dependence on some of Chromium's code. Anyway, just saying that (or that the building process is complicated) cannot be enough to state that Electron is nonfree and one cannot expect Electron's developers to "prove" they have not violated any license.

my point was that electron itself is not interesting to users - only the "apps" built from it are what gets used, and those would be non-free if they did not build from source and mention all licenses

If, doing so, the packaged application is free software, GNU/Linux distributions should do that. Also, I noticed in https://trisquel.info/forum/free-software-foundations-problems#comment-128239 that much code in the "third_party" sub-directory of Chromium is under the GPLv2. If some of that code (and no code incompatible with that license) end up in the pre-built binaries used to easily build Electron-based applications, then that easy build may actually be usable and the resulting application declared under the terms of the GPLv2. I may be wrong though: I am not a lawyer.

so whether the source code of electron is non-free is irrelevant

It is what https://directory.fsf.org/wiki/Free_Software_Directory:Free_software_evaluation suspects. It is what comes up on that forum (and certainly elsewhere), whenever a Electron-based project is mentioned. And it is probably a significant reason for the lack of Electron-based applications in our repositories. And maybe for projects that choose, despite the attractive features of Electron (I guess, given its popularity), to not based themselves on Electron to be free software.

So, if Electron is actually free software, we end up with less free software for no valid reason. It looks relevant to me.

if the author of any one of those files ever claims that it was not licensed for re-use, then the project using it would not only be expected to prove that they have not violated any license, a court would insist upon that

And until that happens (if ever), the developers of the project are considered innocent. That is my point. For the moment, I see no concrete evidence that Electron-based applications (at least if built from source) are nonfree.

Again, I agree such evidences should be more seriously sought than for the average project, because:

• Chromium is nonfree;
• its developers (and those of Chromium's derivatives, such as Iridium) lie when they claim otherwise;
• Electron includes part of Chromium.

But, if nobody can come up with concrete evidences, then Electron should be considered free software (until proven otherwise, if ever).