by Michael Lucas, mwlucas@blackhelicopters.org
This article originally appeared on linux.com. Since they've taken it down, and I'm still rather fond of it, here it is again.
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 had ever happened. 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 requires that source code of modifications be made available when a modified product is redistributed.
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 words "communist" and "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.
The GPL is very good at what it does. The people who use the BSD license simply want something very different than the people who use the GPL. The license has different goals and different motivations than those of the GPL.
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.
A company 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, a company can use BSD-licensed code in specific components, free programmers, and improve their products.
For example, if you want to build 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 company 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 company is reduced.
The end-users get a device that is cheaper and more reliable.
The company still has to do a lot of work to make this happen, though. Developing hardware and software for a fax machine, or any other device, is no easy task. All that the BSD-licensed code does is make a few select parts easy.
Today, Intel has a network appliance based on BSD. So do IBM, Nokia, 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.
Some companies make a good living off of open-source projects. BSDi sells server operating systems based on the BSD UNIX code base. Several open-source projects (namely FreeBSD, OpenBSD, and NetBSD) started from the same BSD UNIX code that BSDi uses. Code from the open-source projects has been incorporated into BSDi. BSDi sells value-added services and support, however, and has also donated code back to the open-source BSD projects.
Why would a company donate hard-won code back to an open-source project? The biggest reasons are cheap debugging, wide test base, and recognition. Open-source developers are quick to point out flaws in code, especially in a project that focuses so much attention on correctness. Open-source end-users frequently run some of the hardest-working machines on the Net, and can put donated code through stress tests the original authors never intended. Finally, knowing that IBM (via Whistle) has donated code back to FreeBSD makes me look upon them much more kindly. Other companies have taken FreeBSD code and not returned anything. They're not required to, but they don't stick in my mind as one of the good guys.
A few FreeBSD corporate users have realized financial benefits from donating code. Whistle Interjet, a subsidiary of IBM, found that minimizing their own local patches they could reduce the amount of work needed to upgrade their own product. This means that their developers can spend their time improving the product, rather than maintaining their OS.
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, have BSD licenses. 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. Even in this day of billion-dollar Internet IPOs, when money for Internet startups is sloshing about like water on the Titanic's deck, 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 Sendmail, they would have to convince the current Sendmail users to pay for something they could still get for free. Any vital, but proprietary, improvement to Sendmail will be duplicated quickly by open-source developers. A closed-source development process cannot withstand the onslaught of open source, 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.
Admittedly, users without source code will have a hard time fixing bugs or adding features themselves. Most companies today have trouble finding people who can make reports off their Access databases, let alone people who could fix device drivers. Companies who have that talent probably already have HylaFax and their preferred free UNIX chugging away somewhere. Most customers fix problems by asking the vendor.
And no code, whether GPLd or BSDL'd, can make up for a company that does not respond to its customers. Starting with known working code can give them a head start, but a non-responsive company still won't go far. You might gripe about Microsoft's quality, but the average user can't handle desktop UNIX yet. The Windows interface might not work well, but it is easy. The average 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 commercial software quality. Can you write an IP stack better than the one in FreeBSD? If not, why bother? Isn't there something you'd rather be doing than handling exceptions for SYNs, ACKs, and RSTs, then returning every six months to deal with the latest denial-of-service attack?
Hundreds of companies have made this same decision; the BSD UNIX 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 about a year ago.
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.
Companies 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 chunks of BSD in Windows.
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 is beginning to accept the idea of open source, and even the GPL. The problem is, we can never be sure what the corporate world will think tomorrow, or next year. After all, twenty-five years ago everyone knew you needed source code to do anything useful. We're returning to that point, but the wheel might keep turning through open source and back the other way.
In 2005, or 2025, 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 corporate policy or legal problems.
Average, everyday people, whose only interest in a computer is from 9 to 5, Monday through Friday, will 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. For developers using the BSD license, freedom is merely a side effect of better software.
Copyright 2000-2001 Michael W Lucas
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice and this list of conditions. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 4. The name of Michael Lucas may not be used to endorse or promote products derived from this material without specific prior written permission.
Return to the main page.