One issue arising out of the Swisslinux/GULL situation is the question of communication tools.
Swisslinux has been operating with a forum while GULL was using a mailing list. Representatives from both groups are now talking about how to join forces and merge these communities.
I've also observed questions like this raised within FSFE, we currently have a lot of mailing lists but there are some people who want to try something like Discourse.
Both technologies have benefits and disadvantages.
One idea I've put forward at RHL'18 today is that it may be useful to have a series of events over the next 12 months, maybe piggy-backed on bigger events, to discuss the way organizations choose their communications tools.
One of the big questions is for organizations to define their goals. If their goals are clear then the choice of tool may be easier and even obvious. Choosing a tool because it is popular or because it is the only thing the sysadmin is willing to support doesn't always result in the best choice for achieving goals.
Would the FSFE community be interested in collaborating on an event or process to study these questions?
Regards,
Daniel
What about upgrading to new Mailman version?
If I recall correctly, it has forum-like functions and keeps the mailing list functions too.
Discourse is somewhat overwork as we would have to patch various parts of it to either remove JS or free/libreate it.
Also, see [1].
[1] https://mikegerwitz.com/2017/06/Don-t-force-me-to-use-your-tools-on-the-Web
2018-01-14T00:49:54+0100 Daniel Pocock wrote:
One issue arising out of the Swisslinux/GULL situation is the question of communication tools.
Swisslinux has been operating with a forum while GULL was using a mailing list. Representatives from both groups are now talking about how to join forces and merge these communities.
I've also observed questions like this raised within FSFE, we currently have a lot of mailing lists but there are some people who want to try something like Discourse.
Both technologies have benefits and disadvantages.
One idea I've put forward at RHL'18 today is that it may be useful to have a series of events over the next 12 months, maybe piggy-backed on bigger events, to discuss the way organizations choose their communications tools.
One of the big questions is for organizations to define their goals. If their goals are clear then the choice of tool may be easier and even obvious. Choosing a tool because it is popular or because it is the only thing the sysadmin is willing to support doesn't always result in the best choice for achieving goals.
Would the FSFE community be interested in collaborating on an event or process to study these questions?
Regards,
Daniel
Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion
On 15/01/18 20:45, Adonay Felipe Nogueira wrote:
What about upgrading to new Mailman version?
If I recall correctly, it has forum-like functions and keeps the mailing list functions too.
Discourse is somewhat overwork as we would have to patch various parts of it to either remove JS or free/libreate it.
Also, see [1].
[1] https://mikegerwitz.com/2017/06/Don-t-force-me-to-use-your-tools-on-the-Web
Thanks for all that feedback
Would packaging the Discourse JavaScript into Debian satisfy those concerns?
Is there enough interest in this topic to start building a wiki page about it?
# Daniel Pocock [2018-01-16 13:43 +0100]:
Discourse is somewhat overwork as we would have to patch various parts of it to either remove JS or free/libreate it.
Would packaging the Discourse JavaScript into Debian satisfy those concerns?
Is there enough interest in this topic to start building a wiki page about it?
I want to highlight that some volunteers are already experimenting with a Discourse instance for FSFE, mainly Nikos IIRC (in Cc). Please join them if you want to support them in their work.
https://git.fsfe.org/fsfe-system-hackers/community
Best, Max
Did you really Cc them? Unless I'm somewhat blind (which is probably true because I already wear glasses to view things better all the time), I couldn't find them in the Cc field of your previous message.
2018-01-16T13:57:11+0100 Max Mehl wrote:
I want to highlight that some volunteers are already experimenting with a Discourse instance for FSFE, mainly Nikos IIRC (in Cc). Please join them if you want to support them in their work.
https://git.fsfe.org/fsfe-system-hackers/community
Best, Max
Hello there!
On 16. Jan 2018, at 13:57, Max Mehl max.mehl@fsfe.org wrote:
# Daniel Pocock [2018-01-16 13:43 +0100]:
Discourse is somewhat overwork as we would have to patch various parts of it to either remove JS or free/libreate it.
Would packaging the Discourse JavaScript into Debian satisfy those concerns? Is there enough interest in this topic to start building a wiki page about it?
I want to highlight that some volunteers are already experimenting with a Discourse instance for FSFE, mainly Nikos IIRC (in Cc). Please join them if you want to support them in their work.
https://git.fsfe.org/fsfe-system-hackers/community https://git.fsfe.org/fsfe-system-hackers/community
+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.
On 18/01/18 10:13, Mirko Boehm wrote:
Hello there!
On 16. Jan 2018, at 13:57, Max Mehl <max.mehl@fsfe.org mailto:max.mehl@fsfe.org> wrote:
# Daniel Pocock [2018-01-16 13:43 +0100]:
Discourse is somewhat overwork as we would have to patch various parts of it to either remove JS or free/libreate it.
Would packaging the Discourse JavaScript into Debian satisfy those concerns? Is there enough interest in this topic to start building a wiki page about it?
I want to highlight that some volunteers are already experimenting with a Discourse instance for FSFE, mainly Nikos IIRC (in Cc). Please join them if you want to support them in their work.
+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.
There is an issue: a) if the JavaScript is distributed as minified blobs and we can't rebuild it easily from source, b) if a large application makes heavy use of things like the NPM repository for its build process
A lot of developers have given up trying to package large JavaScript-heavy web applications for Debian because they are incomplete or not really free software somewhere in the stack or the tool chain.
The front-end developers end up using other repositories like NPM, thinking it is easier than doing something through Debian or Fedora, but it turns out that is just laziness, this type of thing would never happen if the code had been properly packaged:
https://developers.slashdot.org/story/18/01/13/0149252/erroneous-spam-flag-a...
https://developers.slashdot.org/story/16/03/23/0652204/how-one-dev-broke-nod...
Conclusion: if stuff is not properly packaged in the beginning it becomes a minefield for support in the future. If something is in a proper package in a distribution then it is replicated into all the mirrors, the CD images, etc and you can always rely on it being there for you in the future and nobody can pull the rug out underneath you. As FSFE and many other non-profits rely on volunteers for some of the support work we shouldn't be leaving them exposed to things that can disappear like that.
That said, I am keen to see tools developed for replicating things from volatile repositories like NPM and Maven into proper packaging, it is actually a GSoC project[1]. While the emphasis is Java, some parts of the project apply to JavaScript.
Regards,
Daniel
1. https://wiki.debian.org/SummerOfCode2018/Projects#SummerOfCode2018.2FProject...
Hello,
On 18. Jan 2018, at 10:28, Daniel Pocock daniel@pocock.pro wrote:
The client-side Javascript to me is not a relevant issue anymore since JS is an open standard and browsers are sandboxed these days.
There is an issue: a) if the JavaScript is distributed as minified blobs and we can't rebuild it easily from source, b) if a large application makes heavy use of things like the NPM repository for its build process
Accepted. I always assume that software like Discourse is compliant with FOSS licenses, where minified JS code is not “the corresponding source code”. That is usually a choice, though - most packages have a minified and a non-minified source URL. Developers tend to ship with links to the minified version because that is the norm and loads faster. For a Debian packager, this is understandably a problem. We will probably run Discourse out of a container shipped by the project, not a package, so does that still apply to us?
Cheers,
Mirko.
On 18/01/18 10:38, Mirko Boehm wrote:
Hello,
On 18. Jan 2018, at 10:28, Daniel Pocock <daniel@pocock.pro mailto:daniel@pocock.pro> wrote:
The client-side Javascript to me is not a relevant issue anymore since JS is an open standard and browsers are sandboxed these days.
There is an issue: a) if the JavaScript is distributed as minified blobs and we can't rebuild it easily from source, b) if a large application makes heavy use of things like the NPM repository for its build process
Accepted. I always assume that software like Discourse is compliant with FOSS licenses, where minified JS code is not “the corresponding source code”. That is usually a choice, though - most packages have a minified and a non-minified source URL. Developers tend to ship with links to the minified version because that is the norm and loads faster. For a Debian packager, this is understandably a problem. We will probably run Discourse out of a container shipped by the project, not a package, so does that still apply to us?
The real questions:
- can you trust a container to be available in the future the same extent that you can trust a package in a stable Linux distribution?
- can you trust upstream developers to ensure they never put anything non-free into their container images or does somebody have time to verify the contents of those images on every update?
When you take something from an official package, it has usually been looked at by a second set of eyes already. If you cut that step out then how long is it before non-free stuff creeps in?
Regards,
Daniel
Hi,
On 18. Jan 2018, at 10:45, Daniel Pocock daniel@pocock.pro wrote:
The real questions:
- can you trust a container to be available in the future the same
extent that you can trust a package in a stable Linux distribution?
- can you trust upstream developers to ensure they never put anything
non-free into their container images or does somebody have time to verify the contents of those images on every update?
When you take something from an official package, it has usually been looked at by a second set of eyes already. If you cut that step out then how long is it before non-free stuff creeps in?
These are real questions. I don’t have any answers for them. To me the issue of JS in web services is separate from them, though.
Best,
Mirko.
On 01/18/2018 11:02 AM, Mirko Boehm wrote:
Hi,
On 18. Jan 2018, at 10:45, Daniel Pocock <daniel@pocock.pro mailto:daniel@pocock.pro> wrote:
The real questions:
- can you trust a container to be available in the future the same
extent that you can trust a package in a stable Linux distribution?
- can you trust upstream developers to ensure they never put anything
non-free into their container images or does somebody have time to verify the contents of those images on every update?
When you take something from an official package, it has usually been looked at by a second set of eyes already. If you cut that step out then how long is it before non-free stuff creeps in?
These are real questions. I don’t have any answers for them. To me the issue of JS in web services is separate from them, though.
As a developer, I'd like to chip in on this:
1. There's no problem at all in web applications in JavaScript per se. JavaScript is a powerful tool, it's standardized as Mirko said, and of course JavaScript programs can give the four freedoms just as well as every other programming language. Minified versions (corresponding to compiled code) in deployments is also not a problem, since if it's free software the source code will also be available for whoever wants it.
Indeed, JavaScript-based web applications are a perfect candidate for the Affero GPL, and maybe they *should * be under the Affero GPL as a standard recommendation.
2. However, I find containers to be black magic. How can you trust them to be 100% free software if you don't build them yourself? I honestly don't know if Debian's packaging model is a perfect fit for distributing JavaScript, which is, I suppose, why people have come up with npm etc. in the first place. A non-broken NPM or a complete bundling of source code in releases (i.e., pull in the sources of all dependencies and be able to run the source version of all packages in developer mode) would be preferrable. Plone, for instance, tends to bundle its JavaScript itself and allows you to unbundle and unminify everything when debugging.
Best Carsten
On 18/01/18 12:14, Carsten Agger wrote:
- However, I find containers to be black magic. How can you trust them
to be 100% free software if you don't build them yourself? I honestly don't know if Debian's packaging model is a perfect fit for distributing JavaScript, which is, I suppose, why people have come up with npm etc.
I don't think it is about whether Debian's model is perfect or not
Rather, it is about people taking one or more of the following shortcuts:
- they want to use build tools that don't exist in Debian because they are not free software (e.g. jslint, jshint)
- they want to use other JavaScript libraries that are not free software
- they don't want to spend time on little things like creating a proper install directory for their files because they just hack on them in their web server directory
- maybe they don't even release or version their code because they just hack on it as they please
- they like to cut and paste bits of JavaScript from other sites without checking the license
If an organization like FSFE wants to know that the software, dependencies and build tools are all really free software then the "shortcut" to take is to use a Debian package because then you know somebody has checked all those things.
Regards,
Daniel
On 01/18/2018 12:45 PM, Daniel Pocock wrote:
If an organization like FSFE wants to know that the software, dependencies and build tools are all really free software then the "shortcut" to take is to use a Debian package because then you know somebody has checked all those things.
Discourse is under GPL v.2. Is there really a reason to doubt that it's truly free software?
Best Carsten
On 18/01/18 13:10, Carsten Agger wrote:
On 01/18/2018 12:45 PM, Daniel Pocock wrote:
If an organization like FSFE wants to know that the software, dependencies and build tools are all really free software then the "shortcut" to take is to use a Debian package because then you know somebody has checked all those things.
Discourse is under GPL v.2. Is there really a reason to doubt that it's truly free software?
I don't want to comment on Discourse in particular because I haven't checked it but many of the other web applications I've looked at offer a similar free software license for the top-level project but when you scratch under the surface you find at least one dependency or build tool that is not free software.
For example, JSHint chose a free license (MIT) but because they copied a file from JSLint they ran into trouble:
https://github.com/jshint/jshint/issues/1234
When I started looking at HOMER (GNU Affero v3), I found one bad library:
https://groups.google.com/d/msg/homer-discuss/Q-oWrHLTTBU/AaBTAax8DwAJ
So if you can't find every web application in Debian, that is probably a good thing: it means Debian is saving you time by giving you a shortlist of web applications that have already been checked and can be supported.
For any web application, even if everything in the stack is free software, do FSFE volunteers have time to check it every time they take a container directly from the developers of a project? Or would you prefer to save your time and rely on a distribution that does those checks?
One other thing I should have mentioned when Discourse mailing list mode was mentioned: it is not really like a mailing list, it is more like alpha/beta quality compared to real mailing lists. It also obfuscates the email addresses so people can't communicate privately or use PGP.
Regards,
Daniel
On 18/01/18 12:14, Carsten Agger wrote:
- However, I find containers to be black magic. How can you trust them
to be 100% free software if you don't build them yourself? I honestly don't know if Debian's packaging model is a perfect fit for distributing JavaScript, which is, I suppose, why people have come up with npm etc.
I don't think it is about whether Debian's model is perfect or not
Rather, it is about people taking one or more of the following shortcuts:
- they want to use build tools that don't exist in Debian because they
are not free software (e.g. jslint, jshint)
FWIW, none of these are build tools. These are just linting tools, that people use regardless of the packaging/build. I'm personally using ESLint, which is MIT licensed.
- they want to use other JavaScript libraries that are not free software
I understand you point in this thread in general, but using npm or not using Debian packages doesn't necessarily equals using non-free software.
- they don't want to spend time on little things like creating a proper
install directory for their files because they just hack on them in their web server directory
No developer touches a web server directory. At least not on a proper deployment workflow. This is why people use things like package.json and npm/yarn to describe dependencies in an server (and distribution) agnostic way. And then use something like Ansible for deployment.
- maybe they don't even release or version their code because they just
hack on it as they please
It depends. For instance projects like Discourse do version their code. If you are talking about a website, usually there is no need for versioning, especially if you are using a CI/CD workflow.
~nikos
On 01/18/2018 10:28 AM, Daniel Pocock wrote:
There is an issue: a) if the JavaScript is distributed as minified blobs and we can't rebuild it easily from source, b) if a large application makes heavy use of things like the NPM repository for its build process
A lot of developers have given up trying to package large JavaScript-heavy web applications for Debian because they are incomplete or not really free software somewhere in the stack or the tool chain.
The front-end developers end up using other repositories like NPM, thinking it is easier than doing something through Debian or Fedora, but it turns out that is just laziness, this type of thing would never happen if the code had been properly packaged:
https://developers.slashdot.org/story/18/01/13/0149252/erroneous-spam-flag-a...
https://developers.slashdot.org/story/16/03/23/0652204/how-one-dev-broke-nod...
Conclusion: if stuff is not properly packaged in the beginning it becomes a minefield for support in the future.
I was thinking that this warning might in fact apply to my own practices. I don't really work in JavaScript, but I'm using a lot of Python packages in my day-to-day, and I almost never install them from Debian packages.
Why not?
* Versions. Often the packaged versions of Django, Plone, and a lot of others, are outdated. People normally don't install these things from Debian packages. Plone has its buildout system which pulls stuff from PyPI and other repositories, and for Django applications I always use pip against PyPI for installing.
* Non-root install. When using pip and virtualenv, everything can be installed locally. This also means you can fix things in the source code without having or using root access.
* Multiple installs - you can have multiple versions of the same package in non-root environments on the same host - something Django & Plone sites use really a lot.
So there's actually good reasons not to use Python libraries through Debian packages. I imagine the same is the case for JavaScript libraries, not least regarding the necessity of having several different versions coexist in the same OS install.
*On the other hand*, I do realize that if a key dependency suddenly goes missing on PyPI, the applications will break. But I don't think the correct solution for that is to use the Debian package except in very specific circumstances - building an in-house mirror of the dependencies would seem to work better. Or what do you think?
Best Carsten
One way out of these bad practices is perhaps making use of either GNU Guix ([1]) --- which is a package manager that has roll-backs, aims for reproducible builds, avoids bundling and empowers the end-user because it can be used even in non-root, besides it can be installed in any system distribution that has most basic tools from the GNU project --- or GuixSD ([1]) --- a system distribution which uses GNU Guix as package manager and also GNU Shepherd as service/daemon manager.
[1] http://www.gnu.org/software/guix/.
2018-01-31T21:19:27+0100 Carsten Agger wrote:
I was thinking that this warning might in fact apply to my own practices. I don't really work in JavaScript, but I'm using a lot of Python packages in my day-to-day, and I almost never install them from Debian packages.
Why not?
- Versions. Often the packaged versions of Django, Plone, and a lot of
others, are outdated. People normally don't install these things from Debian packages. Plone has its buildout system which pulls stuff from PyPI and other repositories, and for Django applications I always use pip against PyPI for installing.
- Non-root install. When using pip and virtualenv, everything can be
installed locally. This also means you can fix things in the source code without having or using root access.
- Multiple installs - you can have multiple versions of the same
package in non-root environments on the same host - something Django & Plone sites use really a lot.
So there's actually good reasons not to use Python libraries through Debian packages. I imagine the same is the case for JavaScript libraries, not least regarding the necessity of having several different versions coexist in the same OS install.
*On the other hand*, I do realize that if a key dependency suddenly goes missing on PyPI, the applications will break. But I don't think the correct solution for that is to use the Debian package except in very specific circumstances - building an in-house mirror of the dependencies would seem to work better. Or what do you think?
Best Carsten _______________________________________________ Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion
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.
The client-side Javascript to me is not a relevant issue anymore since JS is an open standard and browsers are sandboxed these days.
Hi
I'd like to disagree with this statement.
Mandating javascript is a problem for several reasons:
* Webbrowsers have gotten enormously complex, and not by accident: In my view this is a result of the fight of initially netscape and microsoft, and now google and microsoft for control of the web - piling on features appears to have been a strategy to place the opponent on the back foot. Even if a particular snippet of javascript happens to be GPLv3'ed, the infrastructure running in support of it (eg, the web browser) is probably not. Trying to keep up with this feature race is a red queen problem, and soaks up precious developer time - I would argue this is by design.
* The complexity of a browser (almost certainly the largest piece of software running on most computers) means that securing the sandbox is hard. I would say impossibly hard. The recent Spectre class security issues illustrates this nicely.
Then there are other problems, which aren't directly related to free software issues, but may be relevant to people who would like to use computers ethically:
* The unnecessary bloat of contemporary web browsers means that computers have to be upgraded often and consume too much power. Without this a computer from a decade ago would be perfectly serviceable. Individually this is a minor issue, but in total this is a significant environmental problem.
* The majority of javascript run is not for the benefit of the owner of the computer, but to track, spy on and manipulate the viewer. Much has been said on surveillance capitalism, and I won't repeat it here. But an effective way of opting out of much this is to disable javascript completely. If javascript is mandated by the free software community then it becomes that much harder to opt out.
I understand that many programmers develop for the web, that maybe some on this list regard "being a javascript developer" as part of their core identity, and so might regard these statements an attack on themselves personally. But this is hardly a unique position - coal-powerplant builder, land-mine manufacturer and even butcher or just fisherman all have to face these questions, programmers should not be excluded from those concerns.
regards
marc
On Thu, Jan 18, 2018 at 04:34:50PM +0100, marc wrote:
The client-side Javascript to me is not a relevant issue anymore since JS is an open standard and browsers are sandboxed these days.
I'd like to disagree with this statement.
I fully agree with Marc here.
I would also like to add a more technical note.
That is that no amount of sandboxing exempts a program from havig to follow the Free Software Definition in order to be considered Free Software.
Other than HTML documents and their stylesheets, JavaScript elements are by themselfes programs. Although in a different context the issue of Tivoization[1] has shown a decade ago that compliance to a license does not guarantee compliance to this set of statements which constitute a spirit rather than a law.
[1] https://en.wikipedia.org/wiki/Tivoization
Coercing a user into running specific code in order to view information from your website, leaves this user powerless in regard to this code. The mere permission to serve a modified copy on my own site, and force it over other people in turn, does not change my standing toward the original source, as it would do with desktop software.
Furthermore, strong separation of the browser from the rest of the system, even if it were possible, hardly leads to a gain where this browser and the websites I visit are the focus of my work.
On 01/18/2018 06:32 PM, Paul Hänsch wrote:
On Thu, Jan 18, 2018 at 04:34:50PM +0100, marc wrote:
The client-side Javascript to me is not a relevant issue anymore since JS is an open standard and browsers are sandboxed these days.
I'd like to disagree with this statement.
I fully agree with Marc here.
I would also like to add a more technical note.
That is that no amount of sandboxing exempts a program from havig to follow the Free Software Definition in order to be considered Free Software.
Other than HTML documents and their stylesheets, JavaScript elements are by themselfes programs. Although in a different context the issue of Tivoization[1] has shown a decade ago that compliance to a license does not guarantee compliance to this set of statements which constitute a spirit rather than a law.
[1]https://en.wikipedia.org/wiki/Tivoization
Coercing a user into running specific code in order to view information from your website, leaves this user powerless in regard to this code. The mere permission to serve a modified copy on my own site, and force it over other people in turn, does not change my standing toward the original source, as it would do with desktop software.
Technically, with browser plugins, if the JavaScript is available in a non-minimized form, it /is/ possible to modify it as it runs in your browser. If you interact with a number of specific sites, you could even program these modifications in your own plugins.
So in that way I don't see how JavaScript collides with the Free Software Definition if it's under a free license. Of course, it should be that - releasing software under a non-free license is never morally acceptable.
And note, with this I'm only defending JavaScript for building user interfaces, which I think is far too powerful a tool to be discarded; generally, the Web is far too powerful a technology to be discarded.
With this, however, I'm not defending tracking & advertising JavaScript - my personal hope is that Internet advertising dies, and I don't care at all if it takes Google etc down with it.
Furthermore, strong separation of the browser from the rest of the system, even if it were possible, hardly leads to a gain where this browser and the websites I visit are the focus of my work.
Aren't we all in some way depending on the Web for our work these days? I mean, those of us who work in software. The separation is a good idea because we hope the sandboxing can protect us from the potentially malign effects of software originating from other people's computers. The alternative would be to only visit sites we have reason to trust or only have passive HTML pages.
The first of these alternatives is kind of infeasible (because why *would* you trust your bank, airlines, travel agencies, grocers etc., indiscriminately, together with all of their employees), and the second doesn't appear to be necessary - and as I said, I see many advantages in being able to construct software with JavaScript.
Best Carsten
On Thu, Jan 18, 2018 at 07:27:19PM +0100, Carsten Agger wrote:
Technically, with browser plugins, if the JavaScript is available in a non-minimized form, it /is/ possible to modify it as it runs in your browser. If you interact with a number of specific sites, you could even program these modifications in your own plugins.
This would cover Freedom No. 3.
It would even cover it badly, because the site might require you to update the script anytime to function any further. You could only do this for known scripts, keeping up with all the modifications around would be an overwhelming task. This bares no comparison with actual document standards, where viewing a new document does not require a software update. It leaves the task of reviewing arbitrary changes and keeing up with authors decision to the user, who is forced to either keep up, or become unable to use a site. The relation of dependence here is fundamentally different, from what we are used from desktop software, and...
So in that way I don't see how JavaScript collides with the Free Software Definition if it's under a free license. Of course, it should be that - releasing software under a non-free license is never morally acceptable.
The relation of dependence is also fundamentally different from what we expect Free Software Licenses to provide in a classic case. Those licenses do not do in relation to browser side scripting, what they usually do in relation to software running independently from a service.
And note, with this I'm only defending JavaScript for building user interfaces, which I think is far too powerful a tool to be discarded; generally, the Web is far too powerful a technology to be discarded.
I believe this is a great misunderstanding. Scaling websites to different screen sizes, building menues, building responsive dialogs, play video, etc. does not require the use of JavaScript. For building user interfaces it is simply a sign of bad quality. Web standards to enable those features have been around for at least half a decade, and are nowadays well supported by browsers. Yet websites are increasingly forcing users to enable JavaScript for the most mundane features, just to remain usable. Many web services associated with Free Software make no exception, and are in my view a big part of the problem.
With this, however, I'm not defending tracking & advertising JavaScript - my personal hope is that Internet advertising dies, and I don't care at all if it takes Google etc down with it.
It is not just advertising anymore, and it is not going to die anytime soon. Unfortunately it is perfectly legal to pack any number of antifeatures into a Program under a Free Software license. Free Software was meant to prevent this arrogance by software authors, yet as a Free Software community we have grown accustomed to letting it slip, especially on the web.
Furthermore, strong separation of the browser from the rest of the system, even if it were possible, hardly leads to a gain where this browser and the websites I visit are the focus of my work.
Aren't we all in some way depending on the Web for our work these days?
My point exactly. The idea of a "sandbox" is, that within its boundaries a system can be allowed to do any damage, and it should not affect our work outside this sandbox. Yet when our work happens within the sandbox in the first place, "sandboxing" becomes ridicoulous as an excuse for running untrusted software.
I mean, those of us who work in software. The separation is a good idea because we hope the sandboxing can protect us from the potentially malign effects of software originating from other people's computers. The alternative would be to only visit sites we have reason to trust or only have passive HTML pages.
HTML pages need not to be passive in any way, and to provide a service with a dynamic website it is still not necessary to execute programs on a users computer.
The first of these alternatives is kind of infeasible (because why *would* you trust your bank, airlines, travel agencies, grocers etc., indiscriminately, together with all of their employees), and the second doesn't appear to be necessary - and as I said, I see many advantages in being able to construct software with JavaScript.
My argument goes not against JavaScript as an application language. It is as good a programming language as any, and can be suitable for applications which are installed and run by a user as such.
My argument goes against contrabanding applications as documents for no good reason at all. The web as a library of interlinked documents is too powerful a technology to be discarded to the mindset of software authors viewing themselfes as patron and minister over consumers.
On 01/19/2018 06:04 AM, Paul Hänsch wrote:
And note, with this I'm only defending JavaScript for building user
interfaces, which I think is far too powerful a tool to be discarded; generally, the Web is far too powerful a technology to be discarded.
I believe this is a great misunderstanding. Scaling websites to different screen sizes, building menues, building responsive dialogs, play video, etc. does not require the use of JavaScript. For building user interfaces it is simply a sign of bad quality. Web standards to enable those features have been around for at least half a decade, and are nowadays well supported by browsers. Yet websites are increasingly forcing users to enable JavaScript for the most mundane features, just to remain usable. Many web services associated with Free Software make no exception, and are in my view a big part of the problem.
I think that our different viewpoints may be due to the fact that, as a web developer, I normally don't think of web sites as places to find information, but as programs. This program may, of course, be a CMS like Drupal or Plone, and in that case, no JavaScript is actually needed (even though the Plone guys are currently building a new JS-only interface called Pastanaga which is also a user experience project).
However, that limits the user interaction to the old GET/SUBMIT cycle. With JavaScript, it's possible to do everything you can do in a desktop application, within the limits of the sandbox. This gives us online applications such as LibreOffice Online, Etherpad, etc.
Indeed, one interesting paradigm is the new single-page-applications, i.e., no HTML pages are served by the server at all, the whole user interface is built up client-side in JavaScript, and the server only has to serve the data itself using e.g. a REST API.
If the application is available in a non-minified version, I think this is just as transparent and easy to inspect and debug (using browser tools like Firefox' Inspect facility) as desktop application (which can, indeed, be notoriously difficult to build from source). In other words, I don't see that technology (building user interfaces client-side, in JavaScript) as evil per se, and I see it as no more problematic for freedom than using compiled desktop applications with the source code available. The issue with patching changing code also arises with the constant updates send out, e.g., by Debian.
So - I don't see the use of JavaScript *per se* as problematic or in any way a threat to software freedom.
*Proprietary* JavaScript, however, as served by Google or Facebook or other proprietary software vendors, are another matter altogether. They do indeed violate users' freedom.
Best Carsten
Le 19/01/2018 à 11:21, Carsten Agger a écrit :
I think that our different viewpoints may be due to the fact that, as a web developer, I normally don't think of web sites as places to find information, but as programs. This program may, of course, be a CMS like Drupal or Plone, and in that case, no JavaScript is actually needed (even though the Plone guys are currently building a new JS-only interface called Pastanaga which is also a user experience project).
Hi, this is the problem. HTTP has been devoyed. Another technology should have been invented to create networked applications over Internet.
And Javascript is a real pain: I can't accept that we need now computers more powerful to display some basic informations than games of several years ago. And we don't have the choice. I don't know how I will be able to keep on living in this society.
Hi Carsten,
I largely agree with what you write, but let me challenge you on one point.
*Proprietary* JavaScript, however, as served by Google or Facebook or other proprietary software vendors, are another matter altogether. They do indeed violate users' freedom.
By and large, I believe *where* a certain piece of code runs is immaterial to the question, and what matters is the interface the user of a service is subject to. As we know, throughout the history of computing, we've constantly moved the processing power between the client, and the server, and back again, time and time again.
That Google or Facebook happens to have JavaScript that, today, runs on the client side, should not affect whether it's considered to be violating my freedom or not.
Let's imagine for a second that Google and Facebook rewrote their frontend to use only CSS/HTML, and avoid JavaScript. Would that magically make their service more respecting of my freedom? I do not believe so. It would still be a proprietary service.
And similarly, if they licensed and made available all the corresponding source code for their JavaScript, that would not make the service more respecting of my freedom either. It would still be a proprietary service.
Best,
Hi Jonas
On 01/19/2018 11:50 AM, Jonas Oberg wrote:
By and large, I believe *where* a certain piece of code runs is immaterial to the question, and what matters is the interface the user of a service is subject to. As we know, throughout the history of computing, we've constantly moved the processing power between the client, and the server, and back again, time and time again.
I believe it makes a difference if the software is running on my computer or not.
An aspect of they point you make is that the software run by complex web applications like Facebook or GMail should also be free, we should be able to study it and figure out what it's doing on our behalf when we're pushing its buttons. I think that's the use case of the Affero GPL - by licensing under the Affero GPL, you demand that derived sites should not refuse to make its code, along with its own changes, available to the user.
However, you can't expect to be able to make modifications on other people's servers. What you can do is set up your own server with the same software with the modifications.
In the case of Facebook, likely people wouldn't use your site because you don't have Facebook's database.
And that's in my view a threat to software freedom, but it's a different threat: The centralization. One of FSFE's slogans is "There is no Cloud, just other people's computers".
This is completely true. What is also true is that vast majority of computers in "the cloud" in "The Cloud" is owned by a very small handful of suppliers. So "Cloud computing" is not just an euphemism for "not your computer", it's a euphemism for the fact that ownership of practically all computers in the world, and nearly all public infrastructure, is being concentrated into the hands of maybe three or four cloud vendors. And that's a huge problem.
But, as I argue - it's also a different one.
Best Carsten
That Google or Facebook happens to have JavaScript that, today, runs on the client side, should not affect whether it's considered to be violating my freedom or not.
Let's imagine for a second that Google and Facebook rewrote their frontend to use only CSS/HTML, and avoid JavaScript. Would that magically make their service more respecting of my freedom? I do not believe so. It would still be a proprietary service.
And similarly, if they licensed and made available all the corresponding source code for their JavaScript, that would not make the service more respecting of my freedom either. It would still be a proprietary service.
Best,
Hi Carsten,
I believe it makes a difference if the software is running on my computer or not.
Can you elaborate on how that difference affect your freedom? From my perspective, you would neither gain nor lose freedom if the software runs on your computer or on a remote server. Where it runs feels completely arbitrary in respect to the freedom it offers.
And to follow up, since I can anticipate one answer :-), you can decide what runs or what does not run on your computer. No one is forcing you to run priorietary JavaScript from Google or Facebook. You just need to stop using those services. When you accept to use a service, you also, implicitly agree to the conditions by which that service is offered.
We can disagree with those conditions (and I do), but even if those conditions where not present, it would not affect my freedom (which is none, for those services).
Best,
Hi Jonas,
Je 2018-01-19 13:30:09, Jonas Oberg jonas@fsfe.org skribis:
And to follow up, since I can anticipate one answer :-), you can decide what runs or what does not run on your computer. No one is forcing you to run priorietary JavaScript from Google or Facebook. You just need to stop using those services. When you accept to use a service, you also, implicitly agree to the conditions by which that service is offered.
That doesn't seem quite right. Assuming both the server software and the client software is proprietary, then the difference is indeed minimal, though you could technically reverse-engineer the proprietary client software. But assuming one or both are free, then I would _always_ pick client-side computing over server-side computing, because that gives me greater influence over Freedom 3; the right to modify the software.
If the software exists somewhere on a server, then I would have to run my own server to exercise that freedom, which is often times impractical, sometimes impossible. It is especially impractical when the servers aren't federated. Reddit was for a long time Free Software, but almost nobody ran any Reddit servers of their own, because it is simply no use when all the users and data exist on the _real_ Reddit.
But you're also right; if the terms of services of a certain service are objectionable and the software is not free, then the only thing you can truly do is simply not use the software.
Yours,
Hi Carmen :)
That doesn't seem quite right. Assuming both the server software and the client software is proprietary, then the difference is indeed minimal
Indeed, and this is I guess the core of my argument: whether the proprietary software used to interface with Google runs on my computer, or a remote server, doesn't affect my freedom. What would affect my freedom is if we could get Google to release -- as Free Software -- the interface that runs client side.
That's not likely to happen I suppose :-) But it at least answers the question of what COULD be done to affect our freedom.
On 01/19/2018 01:51 PM, Carmen Bianca Bakker wrote:
Hi Jonas,
Je 2018-01-19 13:30:09, Jonas Oberg jonas@fsfe.org skribis:
And to follow up, since I can anticipate one answer :-), you can decide what runs or what does not run on your computer. No one is forcing you to run priorietary JavaScript from Google or Facebook. You just need to stop using those services. When you accept to use a service, you also, implicitly agree to the conditions by which that service is offered.
That doesn't seem quite right. Assuming both the server software and the client software is proprietary, then the difference is indeed minimal, though you could technically reverse-engineer the proprietary client software. But assuming one or both are free, then I would _always_ pick client-side computing over server-side computing, because that gives me greater influence over Freedom 3; the right to modify the software.
If the software exists somewhere on a server, then I would have to run my own server to exercise that freedom, which is often times impractical, sometimes impossible. It is especially impractical when the servers aren't federated. Reddit was for a long time Free Software, but almost nobody ran any Reddit servers of their own, because it is simply no use when all the users and data exist on the _real_ Reddit.
+1
But you're also right; if the terms of services of a certain service are objectionable and the software is not free, then the only thing you can truly do is simply not use the software.
+1
Le 19/01/2018 à 13:30, Jonas Oberg a écrit :
And to follow up, since I can anticipate one answer :-), you can decide what runs or what does not run on your computer. No one is forcing you to run priorietary JavaScript from Google or Facebook. You just need to stop using those services. When you accept to use a service, you also, implicitly agree to the conditions by which that service is offered.
Except that these are linked to almost every Website and we can't do some activities and have a full social life if we refuse them.
Il 19 gennaio 2018 15:49:43 CET, Stephane Ascoet stephane.ascoet@univ-paris1.fr ha scritto:
[...]
Except that these are linked to almost every Website and we can't do some activities and have a full social life if we refuse them.
I wouldn't call "full" a social life which cannot be lived without proprietary platforms. Maybe "fully controlled" could be a better description ;) OT I'd never ask somebody to stop using proprietary platforms, but I'm not going to use them myself. I just demand people to respect my right to not use them. I'm afraid this might constitute spam, but people don't really have problems reaching me by using phone calls, sms, email, XMPP (conversations.im) or "matrix" (riot.im).
On 20/01/18 08:09, White_Rabbit wrote:
Il 19 gennaio 2018 15:49:43 CET, Stephane Ascoet stephane.ascoet@univ-paris1.fr ha scritto:
[...]
Except that these are linked to almost every Website and we can't do some activities and have a full social life if we refuse them.
I wouldn't call "full" a social life which cannot be lived without proprietary platforms. Maybe "fully controlled" could be a better description ;) OT I'd never ask somebody to stop using proprietary platforms, but I'm not going to use them myself. I just demand people to respect my right to not use them. I'm afraid this might constitute spam, but people don't really have problems reaching me by using phone calls, sms, email, XMPP (conversations.im) or "matrix" (riot.im).
I agree with you here, I have e-mail and phone, my phone number does not get handed out to anyone, as we get enough scam calls, unsolited calls, etc etc as it isl.
I have also made it clear on my website I don't use FB or twitter, I have LinkedIn, diaspora, email and gnu social. All of which you can contact me on.
Paul
Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion
Le 20/01/2018 à 09:09, White_Rabbit a écrit :
I wouldn't call "full" a social life which cannot be lived without proprietary platforms. Maybe "fully controlled" could be a better description
Hi, I don't speak sufficiently English to understand all these little words subtleties but it seems we're not exactly living in the same world. Here to be sure to fully use public transports, we need to be ultra-connected with a pocket-computer(occasionally doing badly phone function). Same thing for going to the theatre, museum and so on. Most organisation's local groups use gayfam services to communicate. If you're not active on these platform, you have no chance to find a job in the private sector, new friends, boy/girlfriend(s). By chance I work in public sector, I'm so much busy that I don't need to find so much people and occupations and I found a loving mate several years ago to continue with the same examples but how would I do if I was younger in this world? And things will become worse and worse: to find an flat, to pay legacy taxes and so on need more and more to compromise ourselves with these technologies. And additionally, finding ways to resist consumes a huge lot of time, energy, money and make us pictured as nerdy and so on. Not very good for social life...
On 2018-01-22 10:10, Stephane Ascoet wrote:
[...] Here to be sure to fully use public transports, we need to be ultra-connected with a pocket-computer(occasionally doing badly phone function).
I suppose "here" means Paris or France. I bet it's possible and not too complicated to use public transports without a pokécom (pocket-computer). You buy a ticket and you hop on. Or maybe you can also buy directly onboard. Like we've been doing for more than one century.
Same thing for going to the theatre, museum and so on.
Ditto. Are ticket booths/websites banned in France?
Most organisation's local groups use gayfam services to communicate. If you're not active on these platform, you have no chance to find a job in the private sector, new friends, boy/girlfriend(s).
I don't believe you: one single counter-example (one single person being able to find a job or a friend) would invalidate your point.
By chance I work in public sector, I'm so much busy that I don't need to find so much people and occupations and I found a loving mate several years ago to continue with the same examples but how would I do if I was younger in this world? And things will become worse and worse: to find an flat, to pay legacy taxes and so on need more and more to compromise ourselves with these technologies. And additionally, finding ways to resist consumes a huge lot of time, energy, money and make us pictured as nerdy and so on. Not very good for social life...
I have been "resisting"* for a while. I don't know how much more time, energy, money I would have if I had given in, but I live a pleasing comfortable life. Anyway, I'm not going to waste more of my time and other people's bandwith arguing while you cannot defend your point with a logical argument. /b
*I feel ashamed using such a meaningful word as "resist" to mean something as ordinary as "not using proprietary platforms".
On Monday 22. January 2018 19.31.44 bruno@tracciabi.li wrote:
On 2018-01-22 10:10, Stephane Ascoet wrote:
[...] Here to be sure to fully use public transports, we need to be ultra-connected with a pocket-computer(occasionally doing badly phone function).
I suppose "here" means Paris or France. I bet it's possible and not too complicated to use public transports without a pokécom (pocket-computer). You buy a ticket and you hop on. Or maybe you can also buy directly onboard. Like we've been doing for more than one century.
Here in Oslo, you can buy tickets on buses, trams and boats, but you pay more to do so. It is possible to buy tickets in advance on underground station platforms and at certain shops, but the emphasis has moved towards selling paperless tickets, meaning that you either have to get the special travel smartcard or use a smartphone.
Interestingly/annoyingly, you cannot add money to the smartcard online, whereas you can pay for travel in the smartphone "app". And I imagine that they will never get round to supporting general online payment because the real aim is to make everyone use their phone.
I think I already mentioned in a previous discussion that the process of checking tickets is prone to failure, because it relies on people's phones having good connectivity and performance. And that is with an underground train network with good mobile coverage relative to some other cities.
It could be worse. When I was at FSCONS in Gothenburg back in 2012, things were already awkward enough that you couldn't buy tickets on the bus at all, meaning that people travelling from the non-central venue back to town who didn't have a smartcard or some kind of mobile device backed with a full Swedish subscription had no way of actually paying for travel, short of walking into town first and then buying a ticket and, well, that makes no sense at all.
(So, one of the locals just suggested not paying and not worrying about any ticket inspection because it was claimed that the inspectors had no legal authority or at least no effective power to demand money from foreigners. What kind of business deliberately makes it difficult for itself to accept money from its customers?)
[...]
Anyway, I'm not going to waste more of my time and other people's bandwith arguing while you cannot defend your point with a logical argument. /b
There's no need to be rude.
Although one can always say that things are not as bad as people claim, there are already places where non-smartphone solutions have been eliminated. Carsten Agger noted in a thread last September ("Is lack of software freedom a valid reason for refusal?") that some parking vendors mandate smartphone "app" usage.
We now risk encountering precisely the kind of "walled garden" Internet that the likes of Apple wanted to cultivate in the early 1990s before the genuine Internet became broadly popular. For a number of good reasons, that is very much something to be worried about.
Paul
Il 22 gennaio 2018 23:39:55 CET, Paul Boddie paul@boddie.org.uk ha scritto:
[...]
There's no need to be rude.
Although one can always say that things are not as bad as people claim, there are already places where non-smartphone solutions have been eliminated. [...]
I absolutely agree, the "mandatory pokécom" problem is real. But emails with a "the sky is falling!" theme without data to back them up drive me crazy. Furthermore the "it's not possible to have a full social life" argument is just false. Anyway, I'm sorry: I should just cool down :)
Le 22/01/2018 à 19:31, bruno@tracciabi.li a écrit :
I suppose "here" means Paris or France. I bet it's possible and not too complicated to use public transports without a pokécom (pocket-computer). You buy a ticket and you hop on. Or maybe you can also buy directly onboard. Like we've been doing for more than one century.
Hi, yes it's becoming very complicated. In Paris, you don't have bus maps anymore on the stops. More and more networks are not printing timetable anymore(like my regional rail network. And they are so badly organised that the times of the trains change from day to day without notice other than being online every second). You can still buy paper-tickets for urban transports but prices are made in a way that it often costs more and they clearly plan to stop them in a few years, like they made for some other things(tax declaration...). For trains, they are closing all the desks, and even on this one, we must argue to have anonymous tickets(and if we suceed they of course cost more). Automatic computerized sellers can distribute only the tickets that the company want us to buy and not the best ones for our destination.
Same thing for going to the theatre, museum and so on.
Ditto. Are ticket booths/websites banned in France?
Almost. Like for transport, you'll have to wait in the hot or cold without being sure to enter and pay more.
I don't believe you: one single counter-example (one single person being able to find a job or a friend) would invalidate your point.
I see that you want to imagine you're living in a great society. How lucky you are. The fall will be hard.
Anyway, I'm not going to waste more of my time and other people's bandwith arguing while you cannot defend your point with a logical argument. /b
*I feel ashamed using such a meaningful word as "resist" to mean something as ordinary as "not using proprietary platforms". _______________________________________________
Well, it's funny how much both of your sentences oppose themselves :-) Anyway we can discuss how much we want this won't change nothing, things will keep on this way(we even have a trader as president in france who is feed by this "new economy" myth every morning) and we'll have to obey or die.
Hello.
I would object to this, in all of the three social stages you are saying would not fit without a cellular phone (I assume the pocket pc is a pun). Speaking from experience, I do just fine with a job, friends and girlfriend and I do not possess a functional cellular phone that I have available. My point is, you are seriously pulling the curtain over your own eyes if you think technology have anything to do with being able to socialize, it does not, period.
Regarding public transportation, museums, theatres and so on I disagree with you that a payment for using such services is legally bound to possessing a computer. You can do the payment just fine with a card or cash.
Just my two cents.
Andreas
On Mon, 2018-01-22 at 10:10 +0100, Stephane Ascoet wrote:
Le 20/01/2018 à 09:09, White_Rabbit a écrit :
I wouldn't call "full" a social life which cannot be lived without proprietary platforms. Maybe "fully controlled" could be a better description
Hi, I don't speak sufficiently English to understand all these little words subtleties but it seems we're not exactly living in the same world. Here to be sure to fully use public transports, we need to be ultra-connected with a pocket-computer(occasionally doing badly phone function). Same thing for going to the theatre, museum and so on. Most organisation's local groups use gayfam services to communicate. If you're not active on these platform, you have no chance to find a job in the private sector, new friends, boy/girlfriend(s). By chance I work in public sector, I'm so much busy that I don't need to find so much people and occupations and I found a loving mate several years ago to continue with the same examples but how would I do if I was younger in this world? And things will become worse and worse: to find an flat, to pay legacy taxes and so on need more and more to compromise ourselves with these technologies. And additionally, finding ways to resist consumes a huge lot of time, energy, money and make us pictured as nerdy and so on. Not very good for social life...
On 29/01/18 09:41, Stephane Ascoet wrote:
Le 28/01/2018 à 13:00, Andreas Nilsson a écrit :
Just my two cents.
Hi, telle me where is the paradise you're living in
You can simultaneously solve your problems with public transport and finding a date by purchasing a motorbike.
Sadly, most modern bikes have ride-by-wire, which means using non-free software. Older bikes may be safer choices.
Regards,
Daniel
Le 29/01/2018 à 09:53, Daniel Pocock a écrit :
You can simultaneously solve your problems with public transport and finding a date by purchasing a motorbike.
Hi, I can't believe how much you're trying to find even the silliest answers to avoid seeing reality, especially here at FSFE!!!
For information I use mainly a Brompton bike in my everyday life but we nobody can't avoid public transport in his entire life... but why I am discussing this...?
Hi Stephane,
Stephane Ascoet stephane.ascoet@univ-paris1.fr writes:
Le 29/01/2018 à 09:53, Daniel Pocock a écrit :
You can simultaneously solve your problems with public transport and finding a date by purchasing a motorbike.
Hi, I can't believe how much you're trying to find even the silliest answers to avoid seeing reality, especially here at FSFE!!!
I am pretty sure Daniel was joking here. I don't think he believes that motorbikes actually get you dates.
Happy hacking! Florian
On 23/01/18 21:24, Florian Snow wrote:
Hi Stephane,
Stephane Ascoet stephane.ascoet@univ-paris1.fr writes:
Le 29/01/2018 à 09:53, Daniel Pocock a écrit :
You can simultaneously solve your problems with public transport and finding a date by purchasing a motorbike.
Hi, I can't believe how much you're trying to find even the silliest answers to avoid seeing reality, especially here at FSFE!!!
I am pretty sure Daniel was joking here. I don't think he believes that motorbikes actually get you dates.
Do you have a motorbike?
Hi Jonas,
Jonas Oberg jonas@fsfe.org writes:
By and large, I believe *where* a certain piece of code runs is immaterial to the question, and what matters is the interface the user of a service is subject to.
Let's imagine for a second that Google and Facebook rewrote their frontend to use only CSS/HTML, and avoid JavaScript. Would that magically make their service more respecting of my freedom? I do not believe so. It would still be a proprietary service.
I agree with you, but I see multiple different questions involved here: 1) Is it Free Software? 2) Do I control my data? 3) Is it ok to execute client-side code (in order to see information)?
So what you describe would satisfy 1 and 3, but Facebook would still process my data in a way I may disagree with. This is a privacy-related question, though, not a Free Software question.
It would still be a proprietary service.
I am not quite sure I would call it that, though. It might even be a free service then that locks in my data.
Happy hacking! Florian
Hi Mirko,
Mirko Boehm mirko@fsfe.org writes:
+1 for investigating Discourse. It was reviewed at the recent community meeting in Berlin and excitement was great.
Just to add to that: Most of the attendees tried out Discourse, at least briefly, and we were all hoping that it would be a useful tool. We did not really reach a conclusion yet, though.
Happy hacking! Florian
I don't know if packaging the JS into Debian would be enough. If I recall correctly, Discourse depends on client-side JS, so the issues are more immediate in the client-side where the client is the one more vulnerable.
There are other things that I didn't have time nor knowledge to check yet, like if Discourse has progressive enhancement.
2018-01-16T13:43:35+0100 Daniel Pocock wrote:
Thanks for all that feedback
Would packaging the Discourse JavaScript into Debian satisfy those concerns?
Is there enough interest in this topic to start building a wiki page about it?
On 16/01/18 16:29, Adonay Felipe Nogueira wrote:
I don't know if packaging the JS into Debian would be enough. If I recall correctly, Discourse depends on client-side JS, so the issues are more immediate in the client-side where the client is the one more vulnerable.
There are other things that I didn't have time nor knowledge to check yet, like if Discourse has progressive enhancement.
In any case, the original intention of this thread was to look at the impact these tools have on the way organizations evolve and achieve meaningful goals, especially free software organizations or those organizations who ask for help from free software experts.
Many people in the street would cite facebook as an example of a good communications tool and some people even use facebook groups to run their organizations. But do those organizations achieve anything? Or do they just attract narcissists or even worse, sap the energy of good volunteers who may have been able to make a more meaningful contribution if they hadn't got stuck in this tool?
Just looking at this thread, we already have an example of the "tool", which is email, impacting the discussion as Adonay brought up the possibility of a CC to system-hackers. In the other thread about the model for local groups, Max suggested moving the discussion to another list: once again, the tool (email) is impacting the discussion.
People tell me that with Discourse, we could @mention somebody from the system hackers or coordinators groups: but in just about every Discourse community that I know of, there are a core group of people who get most of the mentions and answering all of the mentions is just as impossible as answering everything in their email inboxes.
Bug trackers take this a step further: they allow issues to be prioritized so that developers may only look at two or three bugs each week. Could a similar strategy be used in a tool like Discourse, for example, to prioritize which mentions somebody really needs to look at or to give the community feedback?
Another good thing about bug trackers is that they let you see the backlog of things to do and in a company, that might be used to justify hiring more developers. With tools like Discourse, there isn't really a lot of automatic reporting to highlight which individuals or teams are overloaded, people just get frustrated that they are not getting answers or whatever.
Regards,
Daniel
1. https://www.theguardian.com/technology/2012/mar/17/facebook-dark-side-study-...
While there has been a lot of discussion with a focus on Discourse's use of JavaScript, I'd really like to hear feedback from other community members about the high-level issues, such as those raised in my reply below.
One of the original suggestions was to have a series of face-to-face discussions about this - maybe that could happen at FOSDEM or Kamailio World[2], Berlin, in May, where there will be a lot of real-time communication developers present, it is close to FSFE's office[3] and just before MiniDebConf Hamburg[4]?
On a side note, would anybody like to volunteer for an FSFE booth or talk at either of those events? Kamailio World CFP closes 10 February.
On 17/01/18 08:33, Daniel Pocock wrote:
On 16/01/18 16:29, Adonay Felipe Nogueira wrote:
I don't know if packaging the JS into Debian would be enough. If I recall correctly, Discourse depends on client-side JS, so the issues are more immediate in the client-side where the client is the one more vulnerable.
There are other things that I didn't have time nor knowledge to check yet, like if Discourse has progressive enhancement.
In any case, the original intention of this thread was to look at the impact these tools have on the way organizations evolve and achieve meaningful goals, especially free software organizations or those organizations who ask for help from free software experts.
Many people in the street would cite facebook as an example of a good communications tool and some people even use facebook groups to run their organizations. But do those organizations achieve anything? Or do they just attract narcissists or even worse, sap the energy of good volunteers who may have been able to make a more meaningful contribution if they hadn't got stuck in this tool?
Just looking at this thread, we already have an example of the "tool", which is email, impacting the discussion as Adonay brought up the possibility of a CC to system-hackers. In the other thread about the model for local groups, Max suggested moving the discussion to another list: once again, the tool (email) is impacting the discussion.
People tell me that with Discourse, we could @mention somebody from the system hackers or coordinators groups: but in just about every Discourse community that I know of, there are a core group of people who get most of the mentions and answering all of the mentions is just as impossible as answering everything in their email inboxes.
Bug trackers take this a step further: they allow issues to be prioritized so that developers may only look at two or three bugs each week. Could a similar strategy be used in a tool like Discourse, for example, to prioritize which mentions somebody really needs to look at or to give the community feedback?
Another good thing about bug trackers is that they let you see the backlog of things to do and in a company, that might be used to justify hiring more developers. With tools like Discourse, there isn't really a lot of automatic reporting to highlight which individuals or teams are overloaded, people just get frustrated that they are not getting answers or whatever.
Regards,
Daniel
https://www.theguardian.com/technology/2012/mar/17/facebook-dark-side-study-...
2. https://www.kamailioworld.com/k06/ 3. https://fsfe.org/contact/contact.en.html 4. https://wiki.debian.org/DebianEvents/de/2018/MiniDebConfHamburg
On Mon, Jan 15, 2018 at 05:45:34PM -0200, Adonay Felipe Nogueira wrote:
What about upgrading to new Mailman version?
If I recall correctly, it has forum-like functions and keeps the mailing list functions too.
Discourse is somewhat overwork as we would have to patch various parts of it to either remove JS or free/libreate it.
I think you're speculating. Please state clearly what parts should be patched (it's GPL software!).
Also, see [1].
[1] https://mikegerwitz.com/2017/06/Don-t-force-me-to-use-your-tools-on-the-Web
Well, the good thing with Discourse is that you can use it by email when it's properly setup to do so.
*
I am very much interested in the topic of using Discourse to promote the agenda of free technologies and a public digital infrastructure, which I already proposed informally to the FSFE at various occasions. I already proposed to host it myself and offered to use it as an experimental tool in support of the Public Money Public Code campaign.
Interested people can join the Migrators group at
https://ps.zoethical.com/groups/Migrators
== hk
Hi,
hellekin how@zoethical.com writes:
I am very much interested in the topic of using Discourse to promote the agenda of free technologies and a public digital infrastructure, which I already proposed informally to the FSFE at various occasions. I already proposed to host it myself and offered to use it as an experimental tool in support of the Public Money Public Code campaign.
This may have been mentioned before, but there is a Discourse instance at community.fsfe.org.
Happy hacking! Florian
On Thu, Feb 01, 2018 at 07:26:42AM +0100, Florian Snow wrote:
This may have been mentioned before, but there is a Discourse instance at community.fsfe.org.
Hmmm, no there is not, only a broken page. Anyway, if it existed when I proposed my services last year, nobody mentioned it. If it is more recent I find it surprising and upsetting that I have to learn it from the general discussion list. FSFE's community outreach has been, in my experience, suboptimal -- a cool-down euphemism for catastrophic.
Regards,
== hk
Hi,
hellekin how@zoethical.com writes:
Hmmm, no there is not, only a broken page.
Good point and a good reminder for me to check one last time before I send links around. :-)
Happy hacking! Florian
# hellekin [2018-02-01 11:05 +0100]:
On Thu, Feb 01, 2018 at 07:26:42AM +0100, Florian Snow wrote:
This may have been mentioned before, but there is a Discourse instance at community.fsfe.org.
Hmmm, no there is not, only a broken page. Anyway, if it existed when I proposed my services last year, nobody mentioned it. If it is more recent I find it surprising and upsetting that I have to learn it from the general discussion list. FSFE's community outreach has been, in my experience, suboptimal -- a cool-down euphemism for catastrophic.
The Discourse instance, which I think I've explained multiple times on this list, has been set up by volunteers. It is still in a testing status so it's rather senseless for the FSFE to promote it.
Of course you are invited to help them [^1] and help the FSFE and its community to try new communication tools.
Best, Max
[^1]: https://git.fsfe.org/fsfe-system-hackers/community
On 08/02/18 08:27, Max Mehl wrote:
# hellekin [2018-02-01 11:05 +0100]:
On Thu, Feb 01, 2018 at 07:26:42AM +0100, Florian Snow wrote:
This may have been mentioned before, but there is a Discourse instance at community.fsfe.org.
Hmmm, no there is not, only a broken page. Anyway, if it existed when I proposed my services last year, nobody mentioned it. If it is more recent I find it surprising and upsetting that I have to learn it from the general discussion list. FSFE's community outreach has been, in my experience, suboptimal -- a cool-down euphemism for catastrophic.
The Discourse instance, which I think I've explained multiple times on this list, has been set up by volunteers. It is still in a testing status so it's rather senseless for the FSFE to promote it.
Of course you are invited to help them [^1] and help the FSFE and its community to try new communication tools.
Best, Max
Could we have a dedicated sub-domain for anything like this that is running as a test?
Using a domain like "community.fsfe.org" runs the risk that it is perceived as or used as if it were a supported service.
Renaming it to community.test.fsfe.org or community.fsfe-test.org or something similar would be a good idea.
Furthermore, management of the subdomains for testing (call it "lab support") could be delegated to a wider group than management of the main fsfe.org domain (if we consider that to be "production support")
Regards,
Daniel
Hi Daniel,
# Daniel Pocock [2018-02-08 10:32 +0100]:
Could we have a dedicated sub-domain for anything like this that is running as a test?
Using a domain like "community.fsfe.org" runs the risk that it is perceived as or used as if it were a supported service.
In theory yes, but in practice I'm afraid this would cause more work and barriers for our volunteers who want to establish a new service.
To avoid confusion, we explicitly decided to *not* advertise this or other beta services in our communication. When I shared the link on lists like this, I always noted that this is still not in production. I'm not sure that the technical layer you proposed will add any further clarity.
Please also see our guidelines for "volunteer run services":
https://wiki.fsfe.org/TechDocs/VolunteerRunServices
Best, Max
On 08/02/18 09:44, Max Mehl wrote:
Hi Daniel,
# Daniel Pocock [2018-02-08 10:32 +0100]:
Could we have a dedicated sub-domain for anything like this that is running as a test?
Using a domain like "community.fsfe.org" runs the risk that it is perceived as or used as if it were a supported service.
In theory yes, but in practice I'm afraid this would cause more work and barriers for our volunteers who want to establish a new service.
How does using a domain with the word "test" in it somewhere create more work? What about the possibility that people using the service by mistake creates more work too?
Creating a barrier is a deliberate thing though: it mitigates the risk that wider parts of the very large FSFE community start to rely on it before the organization makes a deliberate decision to accept and support the service.
Some effort also has to go into choosing domain names for services, especially in a case like this where it is not clear that "community.fsfe.org" is the only choice. That is bureaucracy but it is hard to avoid it.
To avoid confusion, we explicitly decided to *not* advertise this or other beta services in our communication. When I shared the link on lists like this, I always noted that this is still not in production. I'm not sure that the technical layer you proposed will add any further clarity.
Please also see our guidelines for "volunteer run services":
There is a distinction between people volunteering to maintain a service and the association choosing to rely on a service.
This is particularly important in cases where two services do something similar (e.g. Discourse acts as an alternative to the existing Mailman service). If half the group uses one service and half the group uses the other, you split the organization or you double the amount of effort required to community. Metcalfe's law[1] comes to mind.
As another example, the GA would have to make a decision if we were going to stop using our GA mailing list and use Discourse instead, it wouldn't just happen automatically. So a decision by one group of volunteers (the people who want to run Discourse) impacts other groups and therefore it is a decision for the wider organization to consider. Does that create barriers and bureaucracy? Yes, but isn't that better than the organization splitting over different communication tools?
Regards,
Daniel
# Daniel Pocock [2018-02-08 11:00 +0100]:
There is a distinction between people volunteering to maintain a service and the association choosing to rely on a service.
This is particularly important in cases where two services do something similar (e.g. Discourse acts as an alternative to the existing Mailman service). If half the group uses one service and half the group uses the other, you split the organization or you double the amount of effort required to community. Metcalfe's law[1] comes to mind.
I have to disagree in this case, with the positive experiences from the Git service [^1] in mind. Neither Discourse nor Gitea are/were officially planned to act as a replacement for any service.
Git was something a few community members have wished for, and Björn and me just set it up. We were happy that it didn't entail any huge bureaucrazy [sic], we were able to make some tests right away, and to invite some people to give us feedback. That way we experienced that Gitea can also act as a replacement for SVN in the future and fits nicely in some workflows of our organisation. To make it official, we just had to announce it, no domain change, no votes of huge groups.
Discourse could work similarly. It has been set up by a group of volunteers and we gave them a free hand. Later it might serve as a communication platform for a specific campaign or activity, and if we will make good experiences, other groups and parts of the organisation might think about picking it up for their activities, potentially now as an "official" service. There is no need that we *now* think about replacing the GA mailing list.
In my experience, bureaucracy frustrates volunteers for very good reasons. Let them define a subdomain name, let them hack around, give them some freedom – if such a service ever is ready for organisation-wide usage, we can still think about the details. But devaluate their service by putting a "test" in the domain name would demotivate me as a service maintainer and user at the same time.
And, once again, your proposal solves a non-problem in my opinion. hellekin found harsh words to express his feelings, but his problem wasn't that the service implied to be official but that he didn't know about it.
Best, Max
[^1]: git.fsfe.org
On 08/02/18 11:02, Max Mehl wrote:
# Daniel Pocock [2018-02-08 11:00 +0100]:
There is a distinction between people volunteering to maintain a service and the association choosing to rely on a service.
This is particularly important in cases where two services do something similar (e.g. Discourse acts as an alternative to the existing Mailman service). If half the group uses one service and half the group uses the other, you split the organization or you double the amount of effort required to community. Metcalfe's law[1] comes to mind.
I have to disagree in this case, with the positive experiences from the Git service [^1] in mind. Neither Discourse nor Gitea are/were officially planned to act as a replacement for any service. Git was something a few community members have wished for, and Björn and me just set it up. We were happy that it didn't entail any huge
Git is designed from the ground up as a distributed tool so that is vastly different. I would love to see a mailing list alternative that uses a distributed architecture like Git as a back-end (although it would still be up to the group to decide on using it)
Each project that uses Git can do so without impacting other projects.
Communication tools (Mailman, Discourse, XMPP) are a special case though because everybody needs to use them.
bureaucrazy [sic], we were able to make some tests right away, and to invite some people to give us feedback. That way we experienced that Gitea can also act as a replacement for SVN in the future and fits nicely in some workflows of our organisation. To make it official, we just had to announce it, no domain change, no votes of huge groups.
Discourse could work similarly. It has been set up by a group of volunteers and we gave them a free hand. Later it might serve as a communication platform for a specific campaign or activity, and if we will make good experiences, other groups and parts of the organisation might think about picking it up for their activities, potentially now as an "official" service. There is no need that we *now* think about replacing the GA mailing list.
But it is not that simple. If you start using it for a campaign, you are either a) forcing everybody who interacts the campaign to use it too, or b) isolating the campaign from the rest of the community.
Neither is ideal.
Consider the impact by Metcalfe's Law, imagine we have 200 volunteers using a single communication tool for all campaigns:
Value = 200^2 = 40,000
Now imagine if you have 150 volunteers using email and 50 using Discourse:
Value = 150^2 + 50^2 = 25,000
What Metcalfe's Law is telling us is that an organization committed to a single platform is stronger than an organization that spreads itself over different platforms. It works either way: even if 150 volunteers switch to Discourse and only 50 remain on email, the organization is still weaker.
Note that in this example, I'm ignoring all the other differences between the platforms (e.g. forums like Discourse are more prone to censorship and tampering) and only focusing on the strength of the network.
It is also worth remembering that FSFE needs to communicate with people beyond the community: once again the global email network has a value with Metcalfe's Law, but each forum instance is like a little island.
In my experience, bureaucracy frustrates volunteers for very good reasons. Let them define a subdomain name, let them hack around, give them some freedom – if such a service ever is ready for organisation-wide usage, we can still think about the details. But devaluate their service by putting a "test" in the domain name would demotivate me as a service maintainer and user at the same time.
In fact, we have a similar thing in Debian: any Debian Developer can set up subdomains under debian.net almost instantly but only officially supported things go under debian.org. This strategy has been very successful and is well understood in the Debian community.
Something can only migrate from debian.net to debian.org if there is widespread consensus about it.
It is about the community consciously deciding which direction to go and also being willing to support something even if the volunteers who started it drop out.
And, once again, your proposal solves a non-problem in my opinion. hellekin found harsh words to express his feelings, but his problem wasn't that the service implied to be official but that he didn't know about it.
Well, I hope my calculation with Metcalfe's Law helps people understand why it is a problem, at least when we talk about communication tools.
Best, Max
Hi Daniel,
You are mingling several different ideas here, so let me try to separate them to keep this discussion productive: 1) Should tools not ready for production live under a (sub-) domain separate from fsfe.org? 2) How do we switch teams over? 3) Is Discourse a suitable replacement for E-Mail?
Your original question was 1) and now you are starting to bring up 2) and 3).
Daniel Pocock daniel@pocock.pro writes:
Git is designed from the ground up as a distributed tool so that is vastly different. Each project that uses Git can do so without impacting other projects. Communication tools (Mailman, Discourse, XMPP) are a special case though because everybody needs to use them.
I guess this refers to 2) above. Yes Git is distributed, but everyone in a team that uses Git, needs to use Git. This is the same for a platform such as Discourse. That is why we have team coordinators that can ask the team.
But it is not that simple. If you start using it for a campaign, you are either a) forcing everybody who interacts the campaign to use it too, or b) isolating the campaign from the rest of the community.
Neither is ideal.
Consider the impact by Metcalfe's Law, imagine we have 200 volunteers using a single communication tool for all campaigns:
Value = 200^2 = 40,000
Now imagine if you have 150 volunteers using email and 50 using Discourse:
Value = 150^2 + 50^2 = 25,000
What Metcalfe's Law is telling us is that an organization committed to a single platform is stronger than an organization that spreads itself over different platforms. It works either way: even if 150 volunteers switch to Discourse and only 50 remain on email, the organization is still weaker.
By this logic, we would need to decide for either email or phone or XMPP communication. That is not what this is about. Different teams might want different tools and that is fine. There have been no decisions about anything yet. This is a test and we will see how the community feels. If there is an influx of new interested people because they are more attracted by Discourse then by Mailman, then great, if it is not the case, we will also know. At least until then, the two two tools can coexist.
It is also worth remembering that FSFE needs to communicate with people beyond the community: once again the global email network has a value with Metcalfe's Law, but each forum instance is like a little island.
This refers to 3) and I tend to agree. However, that says nothing about your original question, 1).
Happy hacking! Florian
Hi Max,
while I agree with you in general, I see a small problem here:
On Thu, 08 Feb 2018 12:02:02 +0100 Max Mehl wrote:
Discourse could work similarly. It has been set up by a group of volunteers and we gave them a free hand. Later it might serve as a communication platform for a specific campaign or activity, and if we will make good experiences, other groups and parts of the organisation might think about picking it up for their activities, potentially now as an "official" service.
While git could be tested quite isolated for a few projects, small websites, etc, a discussion platform like Discourse can only be tested if enough people know it and participate.
I almost completely stopped looking at community.fsfe.org, simply because I know nothing happens there. I posted a link to a blog some time ago, but of course no discussion happened because simply nobody knows that community.fsfe.org exists.
If we want to test it seriously we need to advertise it to people who want to discuss FSFE activities and Free Software topic but prefer other tools like email. As long as it is in testing we can add a disclaimer that discussions at community.fsfe.org can disappear at any time in case the test run is not successful.
Cheers, Björn
Hi Björn,
# Bjoern Schiessle [2018-02-08 15:51 +0100]:
If we want to test it seriously we need to advertise it to people who want to discuss FSFE activities and Free Software topic but prefer other tools like email. As long as it is in testing we can add a disclaimer that discussions at community.fsfe.org can disappear at any time in case the test run is not successful.
I completely agree. For the PMPC campaign I thought about using Discourse to be more open to non-technical people (who often prefer mailing lists, like I do) but the platform wasn't ready for a "production" usage yet. If we have a bunch of people using (and testing and error reporting) such a service, I think the move to make it more official is easier.
I like the idea of including a banner or another kind of note at the top of the page with the information that this isn't "official" yet. It may also motivate users to create bug reports.
Best, Max
Hi Daniel,
Daniel Pocock daniel@pocock.pro writes:
How does using a domain with the word "test" in it somewhere create more work?
At some point, a service is at least supposed to go into production, so at that point, configuration files need to change, DNS records need to change, and links to the old subdomain break unless you set up forwarding in the server. That may not sound like a lot, but it is additional work.
What about the possibility that people using the service by mistake creates more work too?
That is a good point. There is a simpler solution to this, though. We can either add a "test" to the logo of the page or add a description that describes the test nature or perhaps both.
Happy hacking! Florian
On 08/02/18 17:51, Florian Snow wrote:
Hi Daniel,
Daniel Pocock daniel@pocock.pro writes:
How does using a domain with the word "test" in it somewhere create more work?
At some point, a service is at least supposed to go into production, so at that point, configuration files need to change, DNS records need to change, and links to the old subdomain break unless you set up forwarding in the server. That may not sound like a lot, but it is additional work.
In many organizations, they keep the test instance running after it goes into production and they use the test instance to test new versions of the code before production upgrades.
So that extra work increases quality and decreases downtime.
What about the possibility that people using the service by mistake creates more work too?
That is a good point. There is a simpler solution to this, though. We can either add a "test" to the logo of the page or add a description that describes the test nature or perhaps both.
That is also a great idea
Regards,
Daniel
I think you're speculating. Please state clearly what parts should be patched (it's GPL software!).
I have started a detailed review in [1]. Discourse has a revision currently approved in the FSD (from 2015, according to the page's history), but this was long before the JavaScript trap article (and issues pointed there) came to exist.
Anyways, in [1] there is shown the output of LibreJS in a demo instance of Discourse. There is also a more detailed evaluation in a posterior section, but only raw results are there (no cleaning was made so far).
Well, the good thing with Discourse is that you can use it by email when it's properly setup to do so.
I hope it's not one of those no-reply emails. ;)
On Fri, Feb 09, 2018 at 03:09:34PM -0200, Adonay Felipe Nogueira wrote:
I think you're speculating. Please state clearly what parts should be patched (it's GPL software!).
I have started a detailed review in [1]. Discourse has a revision currently approved in the FSD (from 2015, according to the page's history), but this was long before the JavaScript trap article (and issues pointed there) came to exist.
Anyways, in [1] there is shown the output of LibreJS in a demo instance of Discourse. There is also a more detailed evaluation in a posterior section, but only raw results are there (no cleaning was made so far).
Hi Adonay, thanks for taking this up!
So what does it say? AFAIK it seems that LibreJS fails to recognize a number of Brotli-compressed assets. But I see no non-free code over there. What would help LibreJS to go green? I guess some licensing tag in the HTML would help it, but apart from that I see no reason to change the FSD approval: do you see any?
Well, the good thing with Discourse is that you can use it by email when it's properly setup to do so.
I hope it's not one of those no-reply emails. ;)
The From: email address is configurable, so you can use a no-reply email. Actually I came to create a private category for Staff and assign it the 'no-reply' address, so that any reply comes to that as a new topic ; you may also assign the address to a group so it becomes like a support email.
== hk
Hi Adonay, thanks for taking this up!
You're welcome! ;)
So what does it say? AFAIK it seems that LibreJS fails to recognize a number of Brotli-compressed assets. But I see no non-free code over there. What would help LibreJS to go green? I guess some licensing tag in the HTML would help it, but apart from that I see no reason to change the FSD approval: do you see any?
The compression/minification is not a problem per see. The issue is that it doesn't have either one of the following (any of these if done will probably be enough):
a) if the scripts are yours, then: an indication for license notice, that is: exact notice as recommended by the license, the reason for this is to make the notice not just readable, but understandable for the visitor/guest/reader. If the goal was readability the notice would be: "Licensed under X" or even just "under X" or "X", but in understandability, it would be: "You are allowed to use, study, adapt share, sell, ... .... under the terms of license X".
To understand this item (item (a)) better, think: How would someone completely new to web-based scripting learn about free/libre software? Certainly, simply inserting "Licensed under X" or "under X" or "X" doesn't help much the case for this new person.
Unfortunatelly, for LibreJS to recognize both the copyright and license indicators, they must be between "@licstart The following is... " and "@licend The above is... " special comments ([1]).
b) if the scripts aren't yours (e.g.: they come from Discourse or from someone else) and together with that they also don't have what is in (a), then: what is missing is a weblabels page, [1] has more information on this.
The references in [2][3][4] also help further explain how to do (a) and (b). The same references also explain alternative ways you can do (a), but with some caveats.
Also I must note that software is a human creation, so it has imperfections just like humans themselves, and I think I found one for LibreJS ([5][6]), which affects the case pointed in (a). Although I think I know why the bug referenced exists, it seems to be an incentive for people to use "-or-later" options for GPL and its family of licenses, and I personally agree with such incentive. ;) In any case, even if LibreJS doesn't recognize a free/libre software license --- say GPL-3.0-only ---, at least we should make the necessary markup prentending it would.
Back to the lack of proper license notices. One must note that in case of minified/compressed/obfuscated JavaScript, the license-related fields aren't the only requirement, this is true for both (a) and (b), and the references I made have more information on this.
Ideally, this should be pushed upstream, and should be the default, not just staying in FSFE's instance, because the benefit and software freedom would be greater if upstream receives this. However, upstream must of course be welcoming to the patches related to this, otherwise we might aswell know beforehand with which community we'd be trusting our communication tool to --- and believe me when I tell you that I already saw multiple hostile people (from either known projects or from websites) either telling me that I should stop or simply refusing my patches.
All in all, you might as well be able to see now that this is no longer a matter of packaging said software into free/libre distros like Trisquel, GuixSD, Parabola or whichever. The issue is really in client-side scripting, and how clarified it is for the guest/visitor of a website.
The From: email address is configurable, so you can use a no-reply email. Actually I came to create a private category for Staff and assign it the 'no-reply' address, so that any reply comes to that as a new topic ; you may also assign the address to a group so it becomes like a support email.
Interesting! ;)
[1] https://www.gnu.org/software/librejs/free-your-javascript.html.
[2] https://www.gnu.org/software/librejs/manual/html_node/JavaScript-Detection.html#JavaScript-Detection.
[5] http://savannah.gnu.org/bugs/?52636.
[6] I plan to add an update to [5] so as to reflect the awesome decision from SPDX project to redo the "-only" and "-or-later" pair of variants for the GPL family of licenses instead of the easily missed no-"+" and "+" pair.
Hi Daniel,
Daniel Pocock daniel@pocock.pro writes:
One idea I've put forward at RHL'18 today is that it may be useful to have a series of events over the next 12 months, maybe piggy-backed on bigger events, to discuss the way organizations choose their communications tools.
I think this is a cool idea. I am very interested in finding the right tools for certains tasks and I would love to find out the advantages and disadvantages of tools that the community already uses.
Happy hacking! Florian