Public Money Public Code: a good policy for FSFE and other non-profits?

[Paul Boddie]

On Wednesday 13. June 2018 15.47.38 Max Mehl wrote:
> # Paul Boddie [2018-06-12 21:53 +0200]:
> > I was surprised that Daniel's motion to document the FSFE's proprietary
> > dependencies, and to describe ways of eliminating them, was so strongly
> > opposed. Is it because admitting such dependencies is embarrassing? Or
> > are there other reasons why no-one else was willing to support it?
> 
> I was at the said GA meeting and we discussed a while about it. I'm
> quite sure Daniel received a more detailed explanation with the reasons
> stated but I don't find it in my archive any more, and my memories
> aren't complete any more.

I appreciate your reply regardless of any reservations you may have about it.

> IIRC, the members brought up two main reasons:
> 
> 1. Which scope should the list of proprietary software in organisation
>    have? Only the OS and applications on our computers and servers? Or
>    does it extend to the landline phones we use? The tax software of our
>    external accountants? The software temporary freelancers like our
>    designers use? Switches in datacenters our servers are located in?
>    Some of the mentioned components will certainly be driven by non-free
>    software.

This is something I briefly addressed in my message:

"Many of us commit to using Free Software exclusively where the right to 
exercise this control has been given to us."

So the embedded software in your phones is probably not an area that would 
need to be covered, in my opinion. I personally use an ancient feature phone 
with a proprietary operating system, and my landline phone is a DTMF device 
that interfaces with the outside world using a voice-over-IP switch delivered 
by the service provider. Although it would be fun to replace all such embedded 
software, it wouldn't be reasonable for others to demand it, nor would it be 
practical or, in the case of the switch, permitted.

> 2. Obviously, we try to use as much Free Software as possible, but
>    unfortunately we cannot avoid all of it, especially on devices and in
>    circumstances we don't a full access to. Does creating such a huge
>    list benefit our work to promote Free Software, or would this create
>    an enormous, ongoing burden for our volunteers and teams,
>    demotivating them because they can't do much about many of those
>    issues?

I agree that the potential impact on volunteers would be problematic. But 
people regularly argue that hosting one's own wiki and repositories is a 
burden and that one might switch to, say, GitHub instead. The path of least 
resistance is increasingly the one most taken. Some people would have 
everything done within Facebook groups because their own personal convenience 
is king. Too bad if one is not on Facebook, I guess.

> Because of the unclear scope, and because most believed that the limited
> advantages of such a project don't outweigh the clear downsides, the GA
> decided to not adopt this motion.
> 
> Disclaimer: all only from the top of my head and IMHO, not speaking for
> the whole GA.

I understand. But did no-one see any merit in the idea? Maybe one of the many 
other, non-Fellow/member/supporter Assembly members might share their thoughts 
with us.

> In my personal opinion, in the FSFE we should trust our people – those
> deeply caring about Free Software and often spending their free time –
> that they don't deliberately use proprietary software for essential
> parts of their FSFE work if there is any better solution. Imposing such
> a motion on them would create more frustration and distraction from our
> actual goal than it would bring any positive effect.

As I see it, the FSFE seeks to provide a platform for campaigning and 
collaboration. Naturally, people can go off and use whatever they want if it 
advances their own interests, but I understood that Daniel's motion would be 
applicable to FSFE-provided facilities. Indeed, Daniel's other motions seemed 
to have some relevance to the effectiveness of FSFE campaigns, and the two 
topics seem to be closely related.

> If you think that we urgently need such a list of proprietary
> dependencies, please try to figure out a balanced definition and think
> of the work involved for different parts of the FSFE.

Well, this matter is not exactly "urgent" to me as such, given that I have 
other activities with higher priorities, including the development of various 
Free Software projects.

Paul