Tag Archives: FSFE

EU-FOSSA needs your help – A free software community call to action

The EU-FOSSA project’s mission is to “offer a systematic approach for the EU institutions to ensure that widely used critical software can be trusted”. The project was triggered by recent software security vulnerabilities, especially the Heartbleed issue. An inspired initiative by EU parlamentarians Max Andersson and Julia Reda, the pilot project “Governance and quality of software code – Auditing of free and open source software” became FOSSA. Run under the auspices of DIGIT, the project promised “improved integrity and security of key open source software”. I had been interviewed as a stakeholder by the project during work package 0 (“project charter, stakeholder interviews and business case”), and later worked with the FSFE group that provided input and comments to the project to EC-DIGIT. While I believe that the parliamentary project champions and the people involved in the project at EC-DIGIT are doing great work, I am worried that the deliverables of the project are beginning to fall short of expectations. I also think the free software community needs to get more involved. Here is why.

When I was approached by the project in the early phase to be interviewed as a representative of the Open Invention Network and a European free software activist, I felt very motivated to help get the project off to a good start. Already during the initial interview doubts emerged about the approach and the apparently pre-conceived ideas of the consultants that had been tasked with the project. Essentially, it seemed they intended to audit Drupal, and wanted the European Commission to do code reviews. These doubts became stronger when the project published a survey about which programs to audit that included 7-zip as a critical free software component, and other funny choices like “Linux – selected system library” without any qualifications. Recently the project began publishing it’s deliverables, and the results gave me and others involved a pause. For example, have a look at Matthias’ comments here. The recommendations show a systematic lack of understanding of the free software/open source community process and the nature of the collaborative peer production performed by them.

Here is a highlight, a “conclusion and recommendation” from section 4.1. Project Management in deliverable 1: “FOSS communities should … use a formal methodology based on PMBOK, depending on their possibilities.” PMBOK or the “project management body of knowledge” (a fat and well-studied volume in my book shelf) is essentially the bible of waterfall project management based on the assumption of working in a large, hierarchical organisation. It is immensely useful in such environments, especially in the public sector. Just not in the wider free software community, which uses mechanisms as self-identification to distribute tasks and depend on voluntary contributions of their participants.

Here is another one, from section 4.2 Software Development Methodology: “FOSS communities should use … agile-based methodologies, according to their resources, so as to make software development more efficient”. Daily scrum anybody, and “the list” of tasks that are allowed to be worked on? Contributors to free software communities, be they individuals or companies, participate voluntarily. They especially do not take assignments or orders from a central coordinating agent, which incidentally does not exist as a role in most relevant communities. Agile methods can be extremely useful and help software teams a lot, but imposing them on a free software project is not an option. The recommendation is also questionable in its premise – that increasing efficiency in community software development is necessary. There are communities with very efficient software development processes (the Linux kernel developers, for example) and others that are not so great. However the efficiency may depend on the number of active contributors, or the complexity of the project goals, or the skill and experience level of the average contributor. Management of development efficiency is a community governance task that defies simplicistic answers like “use this method”. Those are platitudes, and taking them at face value runs the risk of damaging the community development culture.

I could point out more, but as a third example, allow me to highlight a few aspects that did not make it into the report: In deliverable 4, section 4.5 Relevant opinions and advice from interviewees, item 5 says “One possibility is for the European Institutions to do code reviews and share the results with the affected communities.” Sure, however the alternative recommended by FSFE and me and anybody I spoke to about this was for European institutions to not perform code reviews themselves because that is not their area of expertise, and instead to facilitate code reviews in the communities, in cooperation with universities and the national IT security agencies of the member states that already have similar programs in place or are working on them. The pre-conceived idea – the EC should perform the audits – shines through.

In short, the results so far are disappointing, which is sad because the idea behind FOSSA is great, and we should applaud the EU/EC project team for their work and the initiative they took. However the parties performing the research did not hear or fully understand the input and feedback provided by the community. The questionable recommendations are based on a lack of understanding that may in part be caused by tasking generalist research contractors to study the subject. Free software community management is a profession with a difficult subject matter. The fact that everybody can join and participate does not mean that the underlying social process is easy and intuitive to understand for outsiders. We don’t ask painters to recommend medical practises, either.

Because of that, I believe the EC-FOSSA project can still be fixed. The free software community needs to get closer to the project and more involved, study the deliverables and provide feedback and alternative recommendations. The project partners are encouraged to work more directly with the free software communities, and to adopt open and collaborative processes in the project similar to the once used in the communities themselfes. More direct actions to improve the process in the FOSSA project are possible. If this means for EC-DIGIT to step out of the usual procurement routine and set of suppliers of studies, so be it. After all, this is 1 million euro definitely spent for the common good.

Image credit: J. Albert Bowden II, CC-BY, unmodified.

How to campaign for the cause of software freedom


Super secret conspiracy workshop.

Free Software communities produce tons of great software. This software drives innovation and enables everybody to access and use computers, whether or not they can afford new hardware or commercial software. So that’s that, the benefit to society is obvious. Everybody should just get behind it and support it. Right? Well, it is not that easy. Especially when it comes to principles of individual freedom or trade-offs between self-determination and convenience, it is difficult to communicate the message in a way that it reaches and activates a wider audience. How can we explain the difference between Free Software and services available at no cost (except them spying at you) best? Campaigning for software freedom is not easy. However, it is part of the Free Software Foundation Europe’s mission. The FSFE teamed up with Peng! Collective to learn how to run influential campaigns to promote the cause of Free Software. The Peng Collective is a Berlin based group of activists who are known for their successful and quite subversive campaigns for political causes. And Endocode? Endocode is a sponsor of the Free Software Foundation Europe. We are a sponsor because free software is essential to us, both as a company and as members of society. And so here we are.  Continue reading

Hyundai Kia Motors joins the Open Invention Network as the first global automotive manufacturer

Today Hyundai Motor Company and Kia Motors Corporation are joining the Open Invention Network as community members. Linux and Open Source software are becoming a mainstay in automotive computing. With the first global automotive companies joining OIN, a trend has been set towards Open Source collaboration and patent non-aggression in the automotive industry. The news is in the press here on Yahoo Finance, here on Fortune.com and in many other places.

OIN’s community practices patent non-aggression in core Linux and adjacent open source technologies by cross-licensing Linux System patents to one another on a royalty-free basis. Patents owned by Open Invention Network are similarly licensed royalty-free to any organization that agrees not to assert its patents against the Linux System. Within OIN, I am responsible for the maintenance of the Linux System Definition, the field of use for OIN’s patent non-aggression pledge. I am very proud of the great work the OIN team does to protect Linux and Open Source.

The OIN license can be signed online. Ask your company to join the Open Invention Network community, please!

Birthday party at Endocode in Berlin: 30 years Free Software Foundation

On 3 October 2015 Free Software Foundation Europe invites you for the 30th birthday party of the Free Software Foundation. While the main event will take place in Boston/USA, there will be several satellite birthday parties around the world to celebrate 30 years of empowering people to control technology, and one of them will be at Endocode in Berlin.

FSF 30 year birthday graphic

The Free Software Foundation was founded in 1985 and since then promotes computer users’ rights to use, study, copy, modify, and redistribute computer programs. It also helps to spread awareness of the ethical and political issues of freedom in the use of software.

(See the original invitation here…)

The birthday party in Berlin, organised by FSFE, will take place from 15:00 to 18:00 on 3 October 2015 at: Endocode AG, Brückenstraße 5A, 10179 Berlin.

To make sure that Endocode can provide enough birthday cake and coffee, please register before 15 September 2015 for the event by sending us an e-mail with the subject “FSF30″.

Join us on 3 October, celebrating 30 years of working for software freedom!

FLOSS in the Cloud: EOLE, Brussels, Dec 6

Happy Saint Nicholas day everybody! What better purpose could the day be used for to than to travel to Brussels through a storm, and attend the 2013 incarnation of EOLE, the “European Open Source & Free Software Law Event”, held today in Brussels. Philippe Laurent opened the conference with the still blurry question of what cloud is, quoting the FSF: “[cloud] … is a marketing buzzword with no clear meaning…” that is best to avoid. The whole world did not listen and now uses the term widely. The post reflects both what was discussed, and what I learned from the event.

It seems that while the cloud is still opaque, a common understanding is emerging on what cloud computing means. It represents a convergence of all the individual bits of running a service – software, platform, infrastructure, storage, hosting, billing, scaling and more – into a single, standardised, comparable offer. Essentially, it is the message to the engineers that nobody cares about the details, the individual twiddly bits, and clients want one unified package of hosting something that is actually used by a user. Economically, it is another critical step towards massive standardisation of IT operations, making procurement easier because all relevant bits are integrated, and improving competition by making the offers of various providers comparable. We should expect average service prices per user to fall, pretty dramatically, and especially fixed cost overhead in companies that formerly self-hosted to go down as well. In a couple of years, owning your own metal might sound like getting milk delivered to your door in cans.

It helped that Christian Verstraete from HP opened with a detailed overview of OpenStack. It showed the audience that there is a strong convergence of the market towards one free software solution, with backing from 95% of the relevant industry players. A standard test similar to the JavaScript Acid test can be expected to emerge for compatibility between offerings by different cloud providers. With that, migrating from one provider to another should pose no technical issues, only contractual ones. Based on the ForgeRock experience, Lasse Andresen underlined that by stressing that solutions have to be completely free software, not open-core. And the fact that if there is a well-adopted Open Source solution, it cannot easily be killed. In this, the freedoms provided by the licenses do prove useful – companies may fail, but the technology remains.

So far, that was all good, but not very law-related. Things became interesting from a legal point of view when Patrice-Emmanuel Schmitz opened the panel, with his background as one of the authors of the European Union Public Licence. However, he summarised the issues of current licenses and the debate of what distribution or conveying software means for web services, and it seems like that is still mostly murky. The concentration of services into cloud offerings has led to the rise of new licenses (a trend nobody was hoping for, considering the mess of tons of mostly identical not-invented-here licenses that were used a couple of years back). The underlying problem, though, is fundamental: Open Source licensing is based on copyright, which governs reproduction, distribution, adaption and performance of a copyrighted creation. None of these happen under auspices of the user of the site, and therefore there is no copyright relationship regarding the software between the site provider and the consumer. There is a remainder of code being distributed to the user, like JavaScript libraries. It is hard to construe a derivative work relationship between that code and the rest of the application that runs server-side, especially because these JavaScript libraries are often treated more like data than code and not even linked server-side at all. It is more similar to an client-side running interpreter than to a program part. If the web application is not a derivative work of the distributed libraries, the chain is broken, and a provider can claim not to be at fault with Open Sources licenses and not offer the source code for their modifications of the server application. The Affero GPL solves this problem partially by requiring the provider to offer the source code to the user when it is run on the server. This again ties the licensing to an element of the copyright rights bundle, performing. But it leaves a trace of a bad taste, because now there is a problem of proof – the user usually does not know what software was involved in rendering a response. Also, not all server software is licensed under the AGPL or similar licenses.

Contributing to Open Source is not something people do just because the license says so, but because they are somehow driven to collaborate. Web applications can still benefit from the Open Source way. What is different is that for libraries and applications, what the licenses are modelled for, users and developers are effectively treated the same and the distinction only exists in what they do. For web applications, users do not necessarily acquire a right to use, study, modify and improve the source code even if the developers published their product under a copyleft license. This is the norm that made it fun and enjoyable to contribute to Open Source projects. New norms and governance setups should be designed to maintain that situation and thus keep the motivation of contributors (individuals as well as institutions) intact. Compliance should be the norm by now, and I hope that the distrust sometimes underlying the relation – “Are they really showing all the software that is running?” will be a thing of the past.

Many thanks to the organisers!