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?

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

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.

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.

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...

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

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 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 12:14, Carsten Agger wrote:

...

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.

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

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

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 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 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

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 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 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.

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.

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

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".

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 :)

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

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

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

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?

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

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

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

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

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":

https://wiki.fsfe.org/TechDocs/VolunteerRunServices

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

1. https://en.wikipedia.org/wiki/Metcalfe%27s_law

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 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 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

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. ;)

[1] https://directory.fsf.org/wiki/Talk:Discourse.

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.

[3] https://www.gnu.org/software/librejs/manual/html_node/Free-Licenses-Detection.html#Free-Licenses-Detection.

[4] https://www.gnu.org/software/librejs/manual/html_node/Setting-Your-JavaScript-Free.html#Setting-Your-JavaScript-Free.

[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.