From free software to liberal software

Your editor will endeavor to recount the main points of the talk, but there are limits to what can be done with the written word; watching the video is recommended for those who are interested.

Pia Waugh, in her keynote, said that we don't have to carry the systems of the past into the future, that we should challenge our assumptions; that was good advice, r0ml said. Dan Callahan correctly said that free licenses are not enough. Nadia Eghbal told us that we need to think about uncomfortable issues. To that last he posed the question: what is the future of free and open-source software? The answer was: it has no future.

We had set out on a goal to make the world better by liberalizing access to technology. Free and open-source software were a great tactic to advance that goal. Free software had a great run from 1984 to 1998; open-source software had another great run from 1998 to around 2018. But that run is coming to an end, what do we do next? He had three proposals for what the next thing should be: lithification, app freedom, and liberal software.

Lithification

The run of free and open-source software is coming to an end because it is no longer well matched to the substrate of where technology is. Imagine we were still using punched cards; how would one do a merge or a pull request in that environment? The technology would not support such strategies. Our strategies have to match the available technology, and, when the technology changes, we have to come up with new strategies to match.

At this point, he said, the crowd must think he's a bozo. Open source has won, after all. But others, including Tim O'Reilly and Doc Searls, have been saying the same thing. Searls said that we won the battle for Linux, but are losing the battle for freedom — a sad observation. Putting up a Google Trends plot, he showed that searches for "open source" have been in decline for years. The same is true for "free software" — and that includes people looking for free-as-in-beer software. Even plain "software" is in decline, as are searches for "Linux". People may call him a bozo and respond that software is eating the world, but the truth is that the world is eating software.

Searches for "CVS" follow a similar downward path. "Subversion" had a bump, but then went into a steady decline. "Git", instead, has been climbing for years and is still on the way up. Another line that is going up is "app". Yes, apps are just software. But if people think of them as two different things, then that is what they are. "Is Linux an app?", he asked. If it's not, but it is software, then perhaps the two are indeed different.

Small Pieces Loosely Joined is the name of a 2003 book about the web by David Weinberger. But that idea predates the web, it's part of what makes Linux great — pipes allow small pieces to be joined on the command line so that functionality can be composed. But that term also describes lithification, the process by which small grains, initially loosely packed, are compressed into sedimentary rock. That, he said, is what is happening to software.

Putting up a picture of the linux.conf.au web page on a handset, he noted that, if he wants to send it via email, he just hits the appropriate button and it happens. The page can be piped to another app. Zawinski's law says that all programs expand until they can send mail [yes, he said "send" even though the original is "read"]. But now all programs have to be able to do that, as well as send tweets and more. We can build this into our programs, or just make them all talk to each other — small pieces loosely joined.

While preparing the talk, he wanted to add a reference to a book. He thought about creating a barcode-reading app that would allow him to quickly obtain an image of a book's cover, but found that barcode-reading functionality is already built into the iOS and Android systems, along with other features like face recognition and optical character recognition. It's all built into the operating system now. The small pieces have all become a part of the substrate.

But that's Android, not Linux. Perhaps we can say that Android is "Linuxish". How about Windows? Now that it runs Bash and such, it's Linuxish too. Now we have GNU/Linux, Android/Linux, and Windows/Linux. This is a Linux conference, he said, so we can say that, once Linux is a subcomponent of all our other systems, we have won. But, going back to the search trends, it's clear that the world sees Android as being "some other thing that's better than Linux". That hurts.

So what do we do? The reason that commercial Linux is succeeding while free Linux is not is the latter's focus on copyright. Google has a concept called "vendoring"; rather than have dependencies, Google developers simply copy the code they need into their own repository. If that code is BSD licensed, the process is done. You'll have a big repository that you can package and distribute with no dependencies. That is lithification.

Why don't we in the Linux community do that? It feels wrong somehow. But there's a lot of evidence that shows it's a superior solution to the problem. Back in 2000, Butler Lampson, who arguably invented personal computing, argued that a project should only accept dependencies that are at least 5 million lines of code; 20 million lines is better. For anything smaller, just figure out which parts you need, copy them into your repository, and avoid having a dependency to deal with.

We're moving into a different world where the substrate is huge, while apps are getting smaller. Deployment environments are doing the same thing. The whole leftpad() fiasco was caused by developers who couldn't figure out how to implement that functionality themselves, and couldn't figure out how to copy the existing function into their own repositories. Or they could, but there is a social anxiety that prevents them from doing so. But this anxiety is fictitious. Copying the two functions we need from a big library to avoid dependencies is a skill we are all going to need to do lithification after open source no longer works.

App freedom

Bret Victor once said that advanced programming environments conflate the runtime environment with the development-time environment. Open-source methodologies are explicitly about preventing this conflation. But the two should not be separate. This failure to understand can be seen in the four freedoms that define free software. Explaining why this so requires looking at some history, or everybody will just think he's a bozo.

In the 1980s, the world was trying to figure out the best way to build software in a world where programs are large and people have to collaborate to get the job done. One school of thought said that we should just make everybody give their source to everybody else, and that will make it easier to develop software. "But everybody knew that would never work".

The other school of thought was object-oriented programming, where you don't need to see the source for the libraries you're using because the abstraction allows behavior to be clearly described, inherited, and overridden. There would be no issues around conflation of development time and run time or copyright, and we would be able to lithify our software. That didn't work out, and it's now just another legacy we're stuck with, he said. But that was the state of the world at the time.

Also at that time, ordering a GNU CD from the Free Software Foundation was relatively expensive. That expense was arguably unnecessary, but the process of building and delivering the software appeared to have value. That is partly because the recipient was expected to have a computer in their basement to run that software on. But we don't live in that world anymore.

Now, when you use a computer, it's nowhere near you. Almost everything you do is running on a distant machine that you can't download software to or build stuff on. But that's what you want to do: make changes to your code and run it on somebody else's computer. That is the hard part: replicating Google's vast number of servers in your basement. Without that, the second freedom, the ability to modify the software, is lost to us.

Imagine if you wanted to change how GitHub works. If you had the source, all you would need to do would be to reproduce GitHub's entire infrastructure in your basement, make your changes, and convince all of your friends to use the result. Or you could somehow get GitHub to allow you to make the change. The latter is generally easier, and points out another failing in the four freedoms. Freedom 3 is the right to distribute modified versions to others, but, in this world, it's not necessarily access to the source that enables this freedom. Instead, it's access to the runtime environment.

GPLv3 section 6 actively disallows this sort of freedom; it reads:

Anybody who thinks that a network provider couldn't find some reason to proclaim any given change harmful is more optimistic than he is. GPLv3 gives license to that sort of discrimination because it doesn't care what happens at run time; it is only concerned with development time. The authors of the GPL think that development and run time are two different things.

Imagine a world where source-code management was incorporated into a web site. Users could push their own modifications on branches and specify which version they wanted to use. Even if the source is available today, we don't know how to give people the freedom to modify our web sites at run time. We give them the source, but no way to deploy it. That is something we need to change.

When he raises this kind of idea, people immediately start asking questions. How would security issues be handled, for example? Wouldn't it be great, he asked, if there were a community of people out there who understood computers, who were committed to liberalizing access to software, and who might be able to work out technical answers to some of these questions? They might be able to figure something out. He would call the result "liberal software".

Here he took a moment to say that, if you think he's a bozo, you should join the Software Freedom Conservancy to help them defend the free-software world that we have now. If, instead, you agree with him, you should realize that we still need free software until this future is built. So you should still join the Software Freedom Conservancy.

End-user development

Years ago, Guido van Rossum started the "Computer Programming for Everybody" project to pursue a utopian vision in which everybody could program. That didn't work out. Now there seems to be a renewed interest in learning how to program, though it's mostly focused on jobs. But one should consider: what is the most successful programming environment ever created? Excel. More people have solved more problems using spreadsheets than any other way. Spreadsheets don't have separate source and libraries; everything, including the data, is all mixed in together.

Perhaps someday one could request an app by asking Google or Siri to make it. This is a scenario a lot like Excel, with some similar issues, including just where the source code is. An increasing amount of the "source" is personal data stored in databases; nobody would want that to be released. In a world where data and code are intermingled, releasing the result looks increasingly like an invasion of privacy.

So copyright starts to not apply anymore. Already "nobody thinks it's a good idea" as demonstrated by how few GitHub repositories have a license associated with them. Before 1974 software couldn't be copyrighted; it was seen as a mathematical activity. An alternative view said that it was a literary activity instead. The government's view was that it was a useful activity. It was important to the promoters of free software to convince people that software is not useful, because otherwise it would be patentable. We had to invest a lot of energy into copyright and into convincing people that software was not useful, it was literary. We have succeeded with open source.

One can see how the world is changing today. There are already sites that will ask about a user's requirements, then construct a library to suit. As the tooling gets better, constructing such things will become easier. People's freedom will increase as they can construct their own programs and deploy them on infrastructure they don't have to manage themselves.

Some of us, he concluded, are going to have to build that.

[Your editor would like to thank linux.conf.au and the Linux Foundation for assisting with his travel to the event.]