Let’s find some common ground here before we start. For those of you that don’t know, the BSD is an open source software license. It is one of many “competing” licenses that aims at maximizing freedom for some group in the realm of software development and distribution. Specifically, the BSD attempts to maximize this desired freedom by saying as little as possible. Less clauses means less Legalese means less words means less chances to restrict a participant in the software development cycle. This stark simplicity has many implications which I will discuss later in the article.
Note: I’m not going to provide the text of the BSD license here, however short it may be. There’s Wikipedia for that. I want to discourage copying, pasting, and using without thinking (even though I’d love for the world to have more BSD-licensed software). This article merely reflects my own opinions and preferences. Furthermore, I am not a lawyer, so take what I say about this with a grain of salt. But enough with the disclaimers…
As I’ve said before, the BSD is a very simple license. Unlike many of its competitors, it directly restricts only a handful of freedoms, putting it particularly near a declaration of public domain. Most importantly though, the BSD opts to say less about the developer’s liberties, which in turn increases the liberties allowed towards the end user. This is the most important quality of the BSD, because in that regard, it is unique when compared to other open source licenses, such as the GPL.
This simple ruleset manages to elegantly retain developer’s most basic rights to their code while keeping other routes of usage, not traditionally allowed by open source, free for use.
This lack of control allows for corporations, businesses, and users alike to share, copy, sell, and modify the project to their heart’s content. The amount of freedom given to them is very high: users can extend, rebrand, give commercial support for, or even start a business around somebody else’s BSD project. As long as a copy of the BSD license with the original author’s name is retained, the end user basically has the right to do whatever they want with it. The BSD’s sole goal here is the lack of warranty and prevention of somebody claiming other’s work as their own.
This freedom allowed Microsoft to implement Windows networking systems at a minimal cost, and gave Apple a stable base to start Mac OSX from. Rather than having to redesign and implement the wheel, both of these companies could focus on the facets of their respective project thats were the most important. This helped them get their product out of the door, and gave end users a time-tested infrastructure to work on. In short, the BSD isn’t just free. It’s profitable (both monetarily and pragmatically speaking) for all involved parties.
If you know me, it’s no big secret that I’m a fan of minimalism. Philip Glass’ simple arpeggios, Hemingway’s “iceburg” writing style, and the BSD all share an underlying philosophy behind them. Make your point with the least amount of extraneous bells and whistles as possible.
The BSD excels in this arena. Look at the GPL. Now, look at your man — Err, the BSD (reference). In a few short paragraphs, the BSD manages to describe a system of distribution that strikes a perfect balance between exclusivity and openness in a way that’s fair and beneficial to everyone.
Typically, I’ve found that the BSD is very versatile. Whether you’re writing your sassy new jQuery plugin to turn all H2 tags baby blue, or a device driver for an OS kernel, the BSD normally has some type of net benefit to offer you. However, I concede that there are special cases where other licenses might be more apt to your interests.
Sometimes, by choice, you don’t want people to go off and run with your idea or code. This suggests that the GPL may be a better route. This is especially true in academic or learning projects, where your main goal is not utility, but obtaining an increase in personal knowledge. The “cost” of using or modifying your project essentially becomes more open source code given back to you.
Furthermore, not all source code can or should be open sourced. I like to make as much code as I can free or open source, but sometimes you may find that your business is surviving purely because you are the only one that knows how to do something, or at least do it effectively. In these cases, a more limited, or even proprietary license, may suffice.
Cases like these don’t illustrate a failing of the BSD. They only show that you should always take into consideration your goals for any given project. Software licenses should not be a dogmatic matter. No matter how much I like the BSD, I still evaluate different licenses on a per-project basis, because sometimes a different license is just flat out better suited.
Again, I’d like to state that the goal of this article is not to undermine the efforts of the GPL, WTFPL, et. al. I’m only here to provide a rationale for my own preference. That being said, I think the BSD is, in general, a good choice for many kinds of projects. It is open, allows authors to get credit for their work, is compatible with for-profit software, and yet still provides freedom all around the table.