Free and Open—and Their Opposites
A linguistic look at some tenets of Linux.
Merriam-Webster defines a tenet as "a principle, belief, or doctrine generally held to be true; especially one held in common by members of an organization, movement, or profession." As it happens, Linux is claimed by two doctrines that are to some degree at odds: those of free software and open source. This contention began when Eric S. Raymond published "Goodbye, 'free software'; hello, 'open source'", on February 8, 1998. Here's an excerpt:
Specifically, we have a problem with the term "free software", itself, not the concept. I've become convinced that the term has to go.
The problem with it is twofold. First, it's confusing; the term "free" is very ambiguous (something the Free Software Foundation's propaganda has to wrestle with constantly). Does "free" mean "no money charged?" or does it mean "free to be modified by anyone", or something else?
Second, the term makes a lot of corporate types nervous. While this does not intrinsically bother me in the least, we now have a pragmatic interest in converting these people rather than thumbing our noses at them. There's now a chance we can make serious gains in the mainstream business world without compromising our ideals and commitment to technical excellence—so it's time to reposition. We need a new and better label.
Richard Stallman, father of the free software movement, responded with "Why Open Source Misses the Point of Free Software", in which he says, "software can be said to serve its users only if it respects their freedom", and that open source allows software that does not value freedom. Which is true in some cases.
But open source, as Eric and friends intended, won the popularity contest. Today "open source" could hardly be a more common expression—or more out of control, serving as a two-word adjective modifying warfare, law, publishing, ecology, government and much more.
Yet free software has not gone away. Its tenets remain the deeper stratum of bedrock on which open-source tenets lie. The Free Software Foundation also remains intact and influential, as do the Free Software Definition and the Gnu General Public License, which Linux has used from the start.
My purpose here, however, is not to re-hash conflicts between these two tenet-based value systems, but to look for understandings that arise out of considering opposites of the words used to express base values. For example, we could ask, What's the opposite of freedom? A variety of opposites—antonyms—come to mind, starting with slavery and imprisonment, both of which are forms of captivity, so let's lay our first pair out like this:
Freedom is a noun derived from free, which serves as adjective, verb and noun. In the Free Software Definition's title, free takes its adjectival form. To explain, the Definition begins, "'Free software' means software that respects users' freedom and community. Roughly, the users have the freedom to run, copy, distribute, study, change and improve the software." The boldface is in the original and contains a series of transitive verbs, all taking software as their direct object. "With these freedoms", it continues, "the users (both individually and collectively) control the program and what it does for them." Thus, control is what you have with each of those verbs. A clue toward the opposite of control is the verb restrict, which in various forms (including the noun restrictions) appears ten times in the Free Software Definition. In their dictionary definitions, both freedom and liberty are posed against restriction. This leads to our next pair of opposite nouns:
Open is used as an adjective in the Open Source Definition as well. Likewise, restrict and its variants also appear in five of the Open Source Definition's nine criteria, and twice in two of them. Is restricted then also opposite of open, as it is of free? No, because the obvious antonym of open is closed, and closed source is commonly considered the opposite of open source. Yet if you look up "opposite of open source", you'll tend to find the word proprietary.
Back when open source was first being popularized and proprietary was commonly posed as its opposite, Craig Burton told me definitions were being collapsed, and that we could see interesting possibilities if we un-collapsed them. The opposite of open was closed, he said; and the opposite of proprietary was public domain:
If you rotate these two opposites 90 degrees from each other, he said, you could create a 2x2 matrix that looks like this:
He calls this the Burton Matrix, and he has made good use of it through the years to make sense of what different developers choose to do, or to change. For example, he says infrastructural protocols and software, such as the Internet's and Linux, became ubiquitous by working in the upper-right quadrant. One also could place companies, products, services, patents and many other things in various places on the matrix and consider the merits of moving them around. Software that is proprietary yet open in the interoperable sense would fall in the upper-left quadrant. It could "go open source" by moving over to the upper right. One can also "free" something by putting it in the public domain. So if we substitute free for public domain, and take the opposite of free as well, we get this matrix:
This can be helpful for understanding what happens when software, standards, patents and other forms of intellectual property—stuff that is, technically, proprietary—is set free. It moves out of captivity. One example of this is Ethernet, which was developed originally at Xerox PARC, then set free by Xerox, Intel and Digital Equipment Corp. ("DIX"), which together pushed forward standardization of Ethernet's early specifications and implementations. Ethernet was widely adopted because it lived in the upper-right quadrant of both matrices. Everybody was at liberty to use Ethernet without restriction, even though it was proprietary in the sense that it was owned. Thus, it became ubiquitous and essential infrastructure for networking the world. Linux, on the other hand, was born in the upper-right quadrant, and succeeded because competing operating systems, including proprietary UNIX variants, were in either of the left two quadrants. (And let's remember that Linux is a registered trademark of Linus Torvalds, and proprietary in that very limited sense.)
The captive pole is also important to consider as a motivation of technology providers. Large companies especially are biased toward capturing customers and users, and do this with proprietary and closed systems. IBM did this with its Token ring, a proprietary network protocol that competed with Ethernet in the early days.
Linux and Ethernet also won for another reason, which shows up when one looks at design and construction choices, as laid out by Stewart Brand in his landmark book How Buildings Learn. In the first episode of the BBC six-part series of the same title, Stewart begins, "Buildings are the wealth of nations: our largest capital asset. They are the ornament of cultures. And they are where we spend most of our lives. Some of our more arrogant and careless buildings are at war with time and change, and they always lose. Some buildings, though, seem to flow with time. They flow with us." He also asks, "What makes some buildings keep getting better, and others not?" In both the book and the TV series, Stewart unpacks different approaches to architecture and construction that might also be posed as opposites, and arranged on a matrix. (For a detailed examination of these, see my article "The New Vernacular" in the April 2001 issue of LJ.)
The fancy end of architecture Stewart calls magazine. This is architecture as art, where form often defeats function: "Art begets fashion; fashion means style; style is made of illusion; and illusion is no friend to function." With magazine architecture, looks are what matter. They are advertisements for themselves and their creators. The plain end he calls vernacular, which he says "means common in all three senses of the word—widespread, ordinary and beneath notice". He also says it's "what gets passed from building to building via builders and users", and "is informal and casual and astute".
The expensive end of construction he calls high road. This kind is imbued with "high intent, duration of purpose, duration of care, time, and a steady supply of confident dictators". The cheap end he calls low road: "low-visibility, low-rent, no-style, high-turnover", adding, "most of the world's work is done in Low Road buildings, and even in rich societies the most inventive creativity, especially youthful creativity, will be found in Low Road buildings taking full advantage of the license to try things."
Placed orthogonally on a matrix, these two opposites look like this:
Linux is clearly vernacular, but has both low road and high road aspects. At the kernel level, there is high intent, duration of purpose and care, and confident dictators in the form of maintainers. In 2004, when I asked Andrew Morton, one of Linux's top maintainers, if he thought Linux would be around in 200 years, he answered "yes" without hesitation. He also said, "On the kernel team we are concerned about the long-term viability and integrity of the code base. We're reluctant to put stuff in for specific reasons where a commercial company might do that." Yet Linux is also low road in the sense that it's cheap, below the style radar, and ideally suited for doing lots of real work.
With vernacular architecture, you can take either or both roads. Magazine architecture is oblivious to either, which is why Stewart calls it "no road"—even though it does have a way of paving over the low kind. Often you see magazine-worthy buildings going up where low road buildings have been torn down. For example, Lincoln Square in New York and Chavez Ravine in Los Angeles were neighborhoods of low road buildings that were easy for the cities to condemn and replace—in New York with Lincoln Center and in Los Angeles with Dodger Stadium.
In those cases, cities lost neighborhoods. In some cases, there are additional costs in work that can no longer be done because the environment is less friendly to it. A prime example is MIT's Building 20, which Stewart praises in How Buildings Learn for the great heights of its utility, and for the countless inventions and innovations that flowed out of it in the decades that followed World War II, when it was erected as a temporary structure to house work on radar. Despite its nickname—"The Magical Incubator"—Building 20 was replaced in 1998 by the Stata Center, designed by renowned architect Frank Gehry. While the building is clearly distinctive, it is also what Stewart calls an "overpriced, overwrought, unloved, unadaptable, much sued abortion". In other words, the kind of thing Linux's vernacular architects tend to say about proprietary software.
Which gets us back to tenets. Free and open have maximal meaning as nouns and verbs. In The Elements of Style, William Strunk and E. B. White say, "Write with nouns and verbs, not with adjectives and adverbs. The adjective hasn't been built that can pull a weak or inaccurate noun out of a tight place." The Elements of Style is widely regarded as the best book ever written about writing. Like good working code, it is an accumulation of patches. Strunk published the original privately for his classes at Cornell in 1918, and died in 1945. White, a former student of Strunk's, expanded slightly on the original in 1957, and "the little book" quickly became canon. Most of the text from Strunk's original, however, is unimprovable. For example, "Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid detail and treat his subjects only in outline, but that every word tell."
The same might be said of code, and of the tenets that produce the best of it.
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide