Back in 2000, I wrote an essay for Linux.com about why I like the BSD license. It’s actually stood up fairly well to the test of time, but it’s fourteen years old now. Times have changed. So have licenses.

Normally I object to taking something with warts, dosing it with Compound-W, and sending it back out. The structure of the original still holds up pretty well, but experience and history has added new information and context. Any new essay I wrote would look an awful lot like this one.

So, rather than try to write out my opinions from scratch, I’m taking advantage of the Internet and updating my previous essay.

—

Crazed Ferrets in a Berkeley Shower (2014)

When USL sued Berkeley over BSD UNIX, it would have been easiest and cheapest for the university to drop the BSD tapes down a deep well and forget the Computer Science Research Group ever existed. Instead, combining the academic tradition with Berkeley’s well-known liberal spirit, they fought to give their work to the world. In a decision that has caused more arguments than most in the open-source software world, they released the code under the BSD license.

For anyone who has avoided free software licensing for the last five years, the BSD license is very simple: give the authors credit in the source code, and don’t sue the authors if it breaks. There is no requirement to distribute any modifications to anyone. Alternately, the GPL version 2 requires that source code and any modifications be made available when modified code is redistributed. GPL version 3 has additional terms addressing patent indemnification, Tivoization, and more.

Every week sees a new argument on some public forum about how the GPL is free, and the BSD license isn’t. Someone responds that the BSD license is more free than the GPL. Eventually, someone drags out the word “communist,” someone else fires up “corporate exploitation,” and all hope for rational discussion vanishes like free Jolt cola on the trade show floor. It’s better than mud wrestling or Jerry Springer.

Anyone familiar with my work knows that I’m on the BSD side of the fence. The GPL is not a bad thing — as an author I would argue that it’s poorly written as either a software license or a political manifesto, but the whole “share and share alike” ideal is grand. We try to teach our children the importance of sharing. I live sharing. I try to do it myself.

The people who use the BSD license want something very different than the people who use the GPL. The license has different goals and different motivations than those of the GPL. The end goals require different licenses.

Let’s go back in time, to the early days of BSD.

Why would a university, especially such a famously liberal university, struggle to turn a top-notch operating system over to corporations for their pillaging pleasure? BSD UNIX gave thousands of developers the chance to innovate on a solid infrastructure. It raised the bar for minimal acceptable performance in a computer system.

An organization can take a chunk of BSD-licensed code, shrink-wrap it, and resell it. They might make money. But if that’s all that they do, any competitor with an enhancement can take over their market and destroy them. Without real improvements and innovation, BSD-licensed code isn’t as useful as you might think.

On the other hand, an organization can use BSD-licensed code in specific components, free programmers, and improve their products.

If you want to build, say, a networked fax machine you can a) build an operating system from scratch, b) invest in an embedded OS such as QNX, c) use GPL-licensed code, or d) use BSD-licensed code. Most programmers would find building an operating system interesting the first time, tedious the second, and mind-numbingly dull the third. And the organization has to pay for the programmers’ time while he does it. Purchasing an operating system also raises the product’s cost. While the GPL is slowly becoming more accepted, the thought of giving away code still gives most corporate lawyers a bad case of rotating heads and the pea-soup-spews.

By using BSD-licensed code, however, the programmer can spend his time working on the fax machine interface. He isn’t reinventing the wheel yet again. Competitors must improve, or die. The cost to the organization is reduced. The end-users get a device that is cheaper and more reliable.

The organization must do lots of work to make this happen. Developing hardware and software for a fax machine, or any other networked device, is no easy task. All that the BSD-licensed code does is make a few select parts easy.

Today, Intel has network appliances based on BSD. Apple has OS X. So do IBM, Netflix, and a lot of other household names. Entire businesses and careers have been built on BSD-licensed code. They’re big names now, but many of them started with some guy, a basement, and BSD. If the University of California, Berkeley, had not opened their code base under such a non-restrictive license, none of this would be possible. Such intelligent appliances would be far more expensive for both manufacturers and consumers.

Organizations with special code, or some other kind of secret sauce, do not want to release that code to the world. If they’ve spent millions researching how to shuffle bits in a certain way, they want to get their money back. They will not use a GPL code base that requires they release their code to the world. It’s just not going to happen.

While organizations are not required to return code to BSD-licensed projects, many do. Why?

Open-source developers are quick to point out flaws in code, especially in a project that focuses so much attention on correctness. They will happily point out your boneheaded mistakes.

Open-source end-users frequently run some of the hardest-working machines on the Net, and put donated code through stress tests the original authors never intended.

Organizations don’t have to return improments to their source BSD project, but it is in their best interest — for purely commercial reasons. Hardware changes over time, as do operating systems, and this bites organizations in the future. Here’s a true story about a company’s involvement with FreeBSD. I’ve anonymized it and changed some minor details so as to not embarrass them further. (If you were there and watched the fun, please don’t name them.)

Company X produced a product based on FreeBSD 2. It did well. They built a thriving business. Their product required changes to the FreeBSD kernel. Some of these changes were key intellectual property, while others were improvements to related systems that anyone could have done.

They kept all their changes as a single massive patch set.

Time passed. Hardware changed. Company X found that FreeBSD 2 wouldn’t work well for their new hardware. They needed to move to FreeBSD 4.

All of the improvements they made needed to be ported to the new version. Their “secret sauce” had to be rewritten for the new kernel — but so did the less important changes. In many cases FreeBSD developers had improved the systems that Company X’s code patched, but in a way that was totally incompatible with their designs.

Company X realized that if they interacted with the FreeBSD community more and sent their non-proprietary patches back to the project, future merges would be simpler. They could implement the next generation of their proprietary stuff in a way that would fit the FreeBSD development roadmap.

They knew this… but didn’t manage to execute.

Time passed. They had to redo their entire forward porting process for FreeBSD 6.

I don’t know how many times these poor bastards went through this, but I’m glad to say they’re now consistent and regular FreeBSD contributors. (Pain is a wonderful teacher, but nobody wants to go to his school.)

For me, knowing that Company X “gets it” and donates code back to FreeBSD makes me look upon them much more kindly. I know other organizations have taken BSD code and not returned anything. They’re not required to, but they don’t stick in my mind as one of the good guys. I also chuckle when I imagine them merging their code forward.

Some people fear that the BSD license allows companies to take their work and make it proprietary. Source code isn’t a limited resource; any number of people can have it, use it, or improve it. The two programs that hold the Internet together, BIND and Sendmail, had BSD licenses for many years. If a company could seize control of one or another of these programs, the Internet would be their oyster and we would be their slaves. People have tried. People have spent lots of money trying to execute this nefarious master plan. It hasn’t happened. It hasn’t happened because it can’t.

Even if a Big Evil Software Company (tm., pat. pend.) wanted to assimilate BIND, they would have to convince the current BIND users to pay for something they could still get for free. Any vital, but proprietary, improvement to BIND will be duplicated quickly by open-source developers. A closed-source development process cannot withstand the onslaught of open source when it comes to vital core functions, especially when you start with the same code base. Those of us watching the race would have to content ourselves with pointing, laughing, and buying the volunteers beer.

Look at TCP/IP. It was originally implemented in BSD. The BSD implementation became the standard. Everybody uses it. If you write your own stack, it’s expected to be compatible with BSD TCP/IP. Or everyone calls you a loser and says your IP stack sucks. Which it does.

Closed source companies can and do compete on the bells-and-whistles front. And people are willing to pay for the pretty point-and-click interfaces. Heck, more than once I’ve snarled obscenities while trying to make Sendmail relay mail for a specific type of client, and if you asked me at the right moment I would have plopped down a credit card to make the problem go away.

Now, users without source code will have a hard time fixing bugs or adding features themselves. Most organizations today have trouble finding people who can make reports off their Access databases, let alone people who could fix device drivers. Organizations who have that talent use it. Most organizations fix problems by asking the vendor.

And no code, whether GPLd or BSD’d, can make up for an organization that does not respond to its customers. Starting with known working code can give them a head start, but a non-responsive organization still won’t go far. You probably gripe about Microsoft and Apple, but the average user wants an operating system where they can easily install a kitten screen saver with extra spyware. The Windows interface might not work well, but it is easy. The average corporate customers want simple more than they want performance.

From the developer’s viewpoint, code under the BSD license provides a certain “minimal acceptable level” of software quality. Can you write an IP stack better than the one in OpenBSD? If not, why bother? Isn’t there something you’d rather do than handle exceptions for SYNs, ACKs, and RSTs, then return every six months to deal with the latest denial-of-service attack?

Hundreds of organizations have made this same decision; the BSD IP stack has found its way into countless products. Almost any network device that isn’t labeled Linux or System V uses BSD. Some products even combine them; the RTEMS real-time operating system, which is distributed under the GPL, incorporated the BSD IP stack.

Things could have been very different.

Imagine someone travels back in time to the point where the Berkeley regents were choosing the license for their UNIX code. Our time traveler is a very persuasive man, and convinces several regents that they should use the GPL. Most of the others receive a cup of coffee spiked with Richard Stallman’s messenger RNA. The last holdout is distracted on the morning of the final vote by the half dozen crazed ferrets that somehow got in his shower. BSD UNIX receives the GPL.

Consider how the GPL would have been received in the corporate boardroom of the 1980s. BSD UNIX never would have been used.

Organizations frequently build software features such that they work. That’s very different from “they work correctly,” but that’s what we would have gotten.

Imagine SunOS shipping without BSD’s vi; you’d have ed as the default editor. Imagine Digital UNIX with a “good enough” virtual memory system. SVR4 wouldn’t have had long filenames, or job control. The standard Unix File System is a BSD invention; SVR4 would have shipped with the S51K filesystem. A power failure would have meant hours of work using tools like fsdb and clri. If you’ve never heard of fsdb and clri, you don’t want to know about them. Trust me on this one.

If all that didn’t make you flinch: imagine the toll in sheer human suffering if Microsoft hadn’t used the BSD TCP/IP stack.

If Windows was the only competition faced by Linux, Linux would not have come so far. Today, the Linux and BSD camps work every day to outpace each other. We don’t know where that race will end. We do know that the software at the end of it will work.

Today, the attitude towards open source software is quite different than it was in the 1980s. The corporate world accepts open source, and even the GPL. Many will not release their code under the GPL, but they contribute many improvements back to to the BSD world and from there to everyone.

We can never be sure what the world will think tomorrow, or next year. After all, forty years ago everyone knew you needed source code to do anything useful. Twenty years ago, source code was irrelevant for many organizations. We’ve returned to the open source world, but the wheel might just keep turning through open source and back the other way.

Think it can’t happen? Lots of people would like to make Vernor Vinge’s Ubiquitous Law Enforcement real. Many of them have a lot of money. There are alternative scenarios that would crush or marginalize open source operating systems, much as car tinkerers are a fringe group today.

In 2020, or 2030, we might hear the words “Anyone remember the open source fad?” I don’t think it will happen, but history is littered with the rotting corpses of invulnerable juggernauts.

Even if the open source movement collapses, BSD-licensed code will still be used. The open-source BSD groups will have support from people smart enough to recognize the benefits of open source, but who are hamstrung by organizational policy or legal problems.

Average, everyday people, whose only interest in a computer is from 9 to 5, Monday through Friday, benefit. Imagine if your code could, every day, save one thousand people five minutes of annoyance, frustration, or downright hysteria, without them having to know or do anything. BSD-licensed code saves more than that, at no further cost to anyone.

The BSD license is not about open source. Open source is simply a tool to get better software. It’s not about ideology. It’s about correct, stable, and above all, better software, not just for computer-literate individuals but for everyone. It’s about giving users peace of mind, and letting developers do original work.

You’ve got your modern GPLs confused – you state “GPL version 3 requires that source code and modifications be made available to anyone who uses a service provided by that code”, but that’s incorrect. The main difference between GPLv3 and GPLv2 is patent protection – GPLv3 demands that you exonerate anyone using or hacking on your code from any patents you might have on the code. There are also some clauses to try to prevent “Tivoization” in which you’re given copies of the software, but you can’t actually *use* it because of proprietary hardware controllers that refuse to run it. There are some other differences, but those two are by far the most important IMO.

I enjoyed reading the article, btw, but I think you missed the truly key example of why the BSD license is important – TCP/IP.

Forget, for a moment, the BSD operating system itself. Think smaller – think network protocol. Without a BSD-licensed (and world-class performant, for the era) TCP/IP stack freely available for any old joe to pick up and use, the Internet itself would have been delayed decades, and very likely never have looked quite like what it does now. In the 80s, EVERYBODY had their own computer, and WILDLY incompatible featuresets, protocols, languages, and implementations weren’t just rampant, they were /normal/. Hell, they were considered /features/.

Along about this time, “hey, let’s get our computers talking to each other in a better and faster and more extensible way than analog modem squawk” started to be a big deal. Again, forget for a moment the idea of /competing/ computers talking to each other – a single company with a single line of computers wanted their /own/ computers to be able to network. What’s the simplest, cheapest way to do it? Well, here’s this TCP/IP thing, and it’s been thoroughly tested, scales well… oh hey, and here’s a completely free implementation of it that we can port to our own platform with minimal work, and no onerous requirements. Well, duh, OBVIOUSLY we’ll port that rather than spend the development time and money on implementing our own!

/As a side effect/, suddenly pretty much every computer in the world was capable of being networked directly with pretty much every /other/ computer in the world.

A side effect that would DEFINITELY not have happened if the only free implementation of the TCP/IP stack had been GPL, not BSD.

I’m glad Jim Salter brought up the TCP/IP thing – and nicely done too. I read Michael’s article and enjoyed it, but was left slack-jawed when I realized that he completely missed the internet. And that despite the fact that this is where he chose to publish. Michael, you’ve _got_ to work that bit into the next version.

A for profit organization first and foremost motive is profit, if not, they will be non-profit. They might use buzz words “value” or “innovation”, however these are simply the means to achieve the end result.

For instance the recent NSA scandal forced the pro FLOSS company Google to compromise its values.
Redhat is making it harder for Oracle to develop Oracle Linux, and endorsing CentOS to project its free version.
A for profit will fight tooth and nail to maintain its market dominance.

The public is fickle and judges on what it sees. There are articles floating around that suggests that twitter might face the fate of Myspace, as the survival depends on its users.

The other which shutdown in protest of NSA scandal were the two niche email providers. But they knew it better that if they were to compromise, the market for secure email will be marred for the foreseeable future.

Now, coming to the argument of companies being “forced” to release source code is highly subjective. It can be approached from another angle.
Its about strategy and execution.

GPL does achieve this and more, if a competitor does take my code and improves it, that again will reach me back, and in general will benefit the end user. The factor which then differentiates when both of the companies have the same product is the service and delivery. As you mention in your own post, about a organization’s responsiveness to its customers.

Whereas in BSD, this is not always the case. The competitor might try to hold back the improvement on the code just enough to deal damage and my edge is lost.
In worst case scenario, if the competitor becomes a monopoly, it becomes a uphill task to be in the market AND to bring in better standards.

Currently Google is facing this from Samsung and other Chinese manufacturers on Android.
And there is another side-effect, fragmentation. You have many OEMs coming out with their own version of Andorid, which they are free to kill than releasing the source code back to the public.
Similarly you see this on Chrome browser(chromium), though its not that extensive.

And right now the scenario is either you innovate rapidly or fade away.

“GPL does achieve this and more, if a competitor does take my code and improves it, that again will reach me back, and in general will benefit the end user. The factor which then differentiates when both of the companies have the same product is the service and delivery. As you mention in your own post, about a organization’s responsiveness to its customers.

[removed the one distracting part]

Currently Google is facing this from Samsung and other Chinese manufacturers on Android.
And there is another side-effect, fragmentation. You have many OEMs coming out with their own version of Andorid, which they are free to kill than releasing the source code back to the public.
Similarly you see this on Chrome browser(chromium), though its not that extensive.

And right now the scenario is either you innovate rapidly or fade away.

These are the facts, not hypothetical situations.”

These facts describe the situation in the GPL world and it seems you simply didn’t understand the original article which goes to a length explaining why *this* happens due to GPLs nature.