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

Max Mehl max.mehl at
Wed Jun 13 13:47:38 UTC 2018

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

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

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

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.

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.

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.


Max Mehl - Program Manager - Free Software Foundation Europe
Contact & information: | @mxmehl
Become a supporter to enable our work:

More information about the Discussion mailing list