[This blog post is in part taken from a transcript of my presentation at FOSS North 2016 and should be read in that context, some of it relating back to previous postings on this blog]
A critical look at our progress
Allow me to take you back in time. Not very far, but to 2015. This was the year when as many as 78% of companies surveyed by Black Duck Software reported running parts or all of its operations on free and open source software. That's a tremendous penetration of free and open source software. It's also easy to be blinded by such a number.
The same year, 80-85% of all software on Github was proprietary, or at least lacking any sort of indication of being free and open. The number of proprietary repositories on Github, and elsewhere, is increasing.
We're facing a future where more and more companies use and develop free and open source software, while the global portion of free and open source software keeps getting smaller.
I'm not going to lie to you: this is all statistics. And of course, as such, it is at fault: depending on what I wanted to present to you, I could cherry-pick the numbers I felt relevant to my point. And if I polled a group of IT professionals asking them whether they or someone they know is using free and open source software, I'd probably get an astonishingly high number and be very happy about that.
But that number would mean very little about the prevalence of free and open source worldwide: this is the majority illusion. Current discourse tend to favour David over Goliath, leading to the impression that everyone's a David, even if most of us would be sporting a Goliath costume. It's a bit like teenagers and alcohol: everyone thinks everyone else is doing it. And so it is with free and open source software too. Everyone else must be doing it.
And we are in a situation where companies like Sony has been using free and open source software in their TVs since 2003. The Swedish electronics retailer Netonnet has 23 TV models from Sony. 20 of them, 87%, run free and open source software. If you walk into an electronics retailer to buy a TV, there's a very high chance of you walking out of there with free and open source software.
What I'm ignoring in this, to make the point, is of course that a lot of the TVs you walk out of Netonnet with may contain free and open source software, but they also contain a whole bunch of other things. It almost seems as if a lot of electronics you buy today will have the warning somewhere in its documentation:
WARNING, may contain trace elements of free and open source software.
This device's firmware has been compiled with a compiler which also compiles free and open source software.
Free and open source software is, indeed, everywhere. But so is proprietary software. We shall not downplay the success of free and open source software, but let's be realistic: there's a lot more we can and should be doing.
Following the supply chain
Over the past number of years, we've seen the rise of the term supply chain compliance. This isn't specific to software: far from it. Think H&M, Gap or IKEA sourcing clothes and furniture from sweatshops using child labour in Uzbekistan, Bangladesh and Turkey. Supply chain compliance is about managing environmental, legal and social risks of raw material, be they clothes or furniture or software.
Software is the raw material on which we build our future. Marc Andreessen has been talking about how software is eating the world; Larry Lessig was talking many years ago about how code is law. Software is all around us, it influences and controls.
And for this, and many other reasons, if I were to put free and open source software into a TV to be sold to millions of homes, I'd like to have some idea about where that software actually came from: to understand the security and licensing implications. So we follow the supply chain of our TV, from hardware, to software. We follow it from Netonnet to Sony's manufacturing plant in Slovakia, back to Sony's headquarters and r&d facility in Japan, to it's parts suppliers in China and Taiwan.
And we can follow the software components back to where they come from. A lot of times, for embedded, devices, this takes us back to Sweden where Daniel Stenberg is developing curl.
If we are to, as it happens, “manage the environmental, legal and social risks of raw material”, we need to know something about it. We need to know where it comes from. And so, tightly connected with the idea of supply chain compliance, is the idea of software provenance. A term borrowed from the artistic field to mean the “chronology of ownership, custody and location of an object,” in our case: software.
In May 2015, the Software Heritage project set out to archive and index all known free and open source software to date: owing to the understanding that software is also a part of our cultural heritage. Last month, they had indexed about 2,2 billion unique files: from Debian, GitHub and the GNU project. Other build similar archives, for various purposes, but the common denominator is: if we want to know where something comes from, we need to have a database of information to which we can match the source code we're looking for.
The Linux Foundation's working group on SPDX (Software Package Data Exchange) also contribute their piece to the puzzle: a specification for a common language for conveying license and component metadata for software packages.
We're facing an increased awareness of the need for provenance information, not only in software, but also for any type of digital work. The European Commission has signaled that it, from its side, is highly interested in the idea of registries for digital works. And while the motivation to this is sometimes a bit sinister: to be able to detect and punish copyright infringement, the need is no less there.
If we find a piece of software on the Internet, or a snippet of music, or a photograph (think about the work I did for elog.io a while back), and we want to know where it comes from, we currently do not have the technology in place which allow us to do that, for any purpose, with any reasonable success. And if music, photographs, software, is all part of our cultural heritage, not having this information means we're missing out.
And as everyone and their grandma' is pushing for compliance, sometimes to the point where one could wonder if the scaremongering of free software licensing compliance from our own community isn't just as bad as the FUD (fear, uncertainty and doubt) spread by software freedom antagonists.
If you're a single developer, listening to the FUD of the antagonists, and the scaremongering of the protagonists, it's perhaps not so strange to imagine you may do just what James Governor expressed in 2012: fuck the license and governance, just commit to github.
It's a strange irony in that licenses, registries and metadata standards, which are built with the aim to simplify, can be seen as obstructive to development. But for the two sides to meet, the whole process must be as seamless as creating a repository on Github.
We need automation and tooling for licensing and provenance information, and we need it now.
Support structures for free software
In the last half year, no less than three separate initiatives have sprung up in Europe focusing on providing support services and fiscal sponsorship to free and open source software projects. The basic premise is that administration is boring, but someone needs to do it. There are organisations today, such as Software in the Public Interest (SPI), Software Freedom Conservancy (SFC) and the Apache Software Foundation (ASF) who provide a legal home and some services to free software projects.
Independent of each other, at least three different groups have felt the need to do similar work in Europe, and they're all doing it rather differently. The FSFE has a role as an advisor for some of these, and I'll tell you briefly about them.
In the UK, there is some excitement around the possibilities of a relatively recent organisational form called a Community Interest Company. What's special about such entities is that they are for-profit companies with a social objective: each CIC designates in its bylaws the specific community it is supposed to serve, such as the free software community.
Any income generated from its activity may only be used to serve that community, and any assets held: copyright or otherwise, is locked to the specific community. Once a CIC becomes the legal holder of copyright for some software, or funding related to a project, those assets are locked to serve the free software community and may not by law be given elsewhere.
One CIC is in the formative stages and will soon be able to provide some basic services for each of its member projects, but it will also make additional service available as there is a need for them. If a member project wants to register a trademark, as one example, the CIC will help broker the connections and will have service providers for most common functions, but the project will bear the full cost of the registration.
Across the channel, in the Netherlands, is the Dutch foundation Nlnet and it is from their offices that The Commons Conservancy comes. The Commons Conservancy is an organisational hypervisor: the idea is that member projects know themselves what governance structure is most suitable to them, how they should collect and spend money, and so on. The hypervisor does not engage in the day to day operations of the project in any way.
Should the project fail in adhering to its own principles, the hypervisor can step in with some corrective action. Ultimately though, the hypervisor will stay out of the way. If the project decides that it wants to have a governance board consisting of representatives of the world's Fortune 500 companies, that's just as valid as having a benevolent dictator for life. What the hypervisor cares about is that any decision regarding the direction has been taken in a way which is consistent with the guidelines and processes already established by the project.
Each of these ideas, a CIC and the Commons Conservancy, as well as others, will serve a need for some projects to have an organisational home. Their challenge is to avoid being the graveyard of projects which failed to gain traction. But in terms of new developments, this is something that's bound to come up even more during the rest of the year.
The opportunity of a single market
An opportunity which lie ahead of us is the Digital Single Market (DSM), a strategy aimed at bringing down regulatory barriers between the 28 different national markets.
According to the Commission, a true Digital Single Market (DSM) can be achieved by taking the following actions, and I quote:
- Digitalising industry to a smart industrial system so that all industrial sectors should be able to integrate new technologies.
- Developing standards and interoperability in areas such as the "Internet of Things", cybersecurity, big data, and "cloud".
- Launching initiatives on the "free flow of data" and a European Open Science Cloud as a catalyst for growth, innovation and digitisation.
- Unlocking the benefits of high-quality e-services and advancing digital skills.
This is a significant investment from the Commission in terms of time, political clout and actual resources. The Research Executive Agency, which is funding research based in part on the priorities of the European Commission and Parliament, is investing a lot of hard cash into technologies that can be seen as meeting parts of those actions.
A lot of political initiatives that relate free software is also part of the DSM: the different implementations of copyright law in different states has been seen as an obstacle to a single market and the legislative proposals for copyright reform that are being discussed should be seen in the light of bringing down regulatory barriers for a single market.
The DSM also highlight the importance of legal certainty for text and data mining, but doesn't offer any concrete ideas for the direction of this. But any legislation which deal with text and data mining should be seen in the light of a single market. It's not about text and data mining per se, but about bringing down regulatory barriers.
But this is the opportunity: by anchoring our ideas and activities to the DSM, we can gain some traction for those activities, and it opens up some doors that would otherwise be closed. The DSM is one of the Commission's children. As any parent, they love to talk about it.
Legal developments in free software
A few months ago, I had the pleasure listening to a legal expert talk about a subject with a waiver saying: I'm not even sure I agree with what I'm saying. Mind you, this is specific to US copyright law, but it's non the less interesting to reflect on.
US copyright law defines a copyrightable work as something which has been fixed at any particular time. Where a work has been prepared in different versions, each version constitutes a separate Work.
However, case law in the US dictate that separate copyrights are not separate Works UNLESS each Work has an independent economic value in itself.
In free and open source software, we have the concept of a derivative work, where each addition or change from a contributor creates a new Work. Each derivative forms a new Work and each derivative of this forms a new Work and so on. US case law, again, however, say that a derivative work is what occurs when an independent expression to an existing work effectively creates a new work for a different market.
Indeed, even Google argued last year in a case that a definition of a derivative work that implies the creation of a new work based on a very small level of creativity or originality would “make swiss cheese of copyrights.”
We haven't seen this in software, in this way, but we know it from the film industry. There has been cases where actors have agreed to portray a character in a film, only to have the producer dub over their voices to make their characters say and act completely different from what the actor intended and agreed to.
Courts have ruled that the individual contributions of the actors can not have an independent value in itself, and as such, they do not enjoy copyright protection as separate works.
In LLC v. Merkin in 2015, the 2nd circuit court ruled that:
May a contributor to a creative work whose contributions are inseparable from, and integrated into, the work maintain a copyright interest in his or her contributions alone? We conclude that, at least on the facts of the present case, he or she may not.
In cases in which none of the multiple-author scenarios specifically identified by the Copyright Act applies, but multiple individuals lay claim to the copyright in a single work, the dispositive inquiry is which of the putative authors is the “dominant author.”
[...] Deciding who is the “dominant author” is includes the parties' relative control over what changes are made and what is included in a work (the Decision-making authority)
You can imagine what this can mean, if you make this claim about the Linux kernel: if Linus Torvalds is the decision-making authority, deciding what changes are made and what is included in the Linux kernel, then by some arguments, Linus could be seen as the dominant author and thus the single copyright owner of the work.
It's worth pointing out this is at best speculative, and may only apply, even if it were to apply, to US copyright law. But it's an interesting reflection on copyright law and the complexities thereof as it relates to software.
The case of centralisation
Moxie Marlinspike and his Open Whisper System has met some criticism over their Signal product. Signal is a tool for secure messaging between mobile devices. The criticism is that Signal is built on a centralised platform. This was fueled even further by an idea that LibreSignal, an independent build of Signal, would not be able to federate and talk to the Signal servers.
In a response to this critique, Moxie wrote about how he feels that innovation can not happen as quickly and easily as needs be with federated and decentralised structures. To prove his point, he argued that the premise that the internet could not have gotten to where it is without interoperable and federated protocols is false:
We got to the first production version of IP, and have been trying for the past 20 years to switch to a second production version of IP with limited success. We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s. That's how far the internet got. It got to the late 90s. ”
I don't necessarily agree with Moxie, and I think you may not either. But Moxie has a point in that federated structures are more difficult to achieve. Historically, they only develop after considerable investment into non-federated structures: think telephones, trainlines, electricity grids, water & waste management, and so on.
The Internet of the late 90s was built on knowledge of the success and failures of thousands of non-federated networks around the world. There's no reason to think this will not happen again, and that encrypted personal communication is not an area where such a change is ripe to happen.
But we do not always have direct control over the twists and turns of technological progress. And I do say progress, with the implied meaning that a free and open source software federated structure for encrypted communication would be a progress beyond what we have today.
Until we have that in place, we must do what we can, in each of our ways, to work politically, socially and technologically for free and open source software. And sometimes, as it relates to technologies we all use and depend on every day, we may find it useful to remind people, with a tongue in cheek manner, that There is No Cloud – Only other people's computer.