In defense of BSD licensesJuly 14, 2009
Zed Shaw just blogged about why he uses the GPL instead of a BSD-style license. His arguments for the GPL are interesting but I feel that counterpoint is needed, since at Enthought (where I work), we try to BSD as much of our code as possible.
“It’s the Author’s Right”
First off, I’d like to encourage everyone in the Python community to be respectful. It is never appropriate to get angry at another person for their choice of license, and I am disappointed that Zed feels slighted by the community reaction to his work. (If you don’t like the license on a package, it is sometimes appropriate to ask the author if they’d consider changing it, but obviously beggars can’t be choosers.) Hopefully it’s just a few bad apples (“ungrateful turds”, as he calls them). That being said, “it’s the author’s right” is not really a reason for the GPL, just an admonishment.
“I Don’t Want To Be Ignored Again”/”You Have To Tell Your Boss You’re Using My Gear”
The fact that Zed wrote Mongrel and got no recognition is possibly an indictment of several things: the RoR buzzstorm, the Rails community, the “OMG Ruby is the new Java for Web 2.0″ technorati, maybe even venture capitalists. But it is not an indictment of the BSD license.
Numpy and Scipy are two very successful projects, and they are BSD licensed. They have healthy communities, and many people make a living off of consulting work or commercial projects built on those tools. There are also countless companies whose staff make use of them internally, and occasionally give back to the projects. I would consider both Numpy and Scipy to be healthy, open-source projects with plenty of mature collaboration between commercial, academic, and hobbyist users. If either project were suddenly to become GPL, they would lose their commercial viability and the communities would undoubtedly suffer.
SAGE, an open-source Pythonic replacement for Maple/Mathematica/Magma/Matlab, is another very successful project, but they staunchly use the GPL. Their reasoning is much like Zed’s, because the symbolic math software community has been burned in the past by people profiting from proprietary extensions of BSD code without attribution or contribution. However, the GPL means that people cannot realistically use SAGE in a commercial tool, either as a platform/runtime, or as an embedded component. The SAGE authors have, presumably, weighed the trade-offs and decided it’s ultimately more valuable to be protected than to have the contributions of that segment of developers.
The style of license both depends on and defines the type of community that develops around a project. If you feel that the potential audience of your project consists of the sort of people that are liable to use your code without attribution and without becoming part of the user community, then by all means protect yourself with the GPL. If your code is the outgrowth of a community that already has a healthy number of commercial users, then there’s usually no downside risk of using BSD, while you get the upside of reaching a larger audience. Based on what I’ve seen, the Python community has a pretty healthy mix of commercial developers, and so as a whole I don’t think people there get burned by choosing the BSD license.
“If It’s Good, Pay For It”
Here is where we are in agreement, but there are numerous ways to approach this. Phil Thompson uses a dual licensing scheme with PyQT, wherein commercial developers have to pay for it. Travis Oliphant implemented an interesting “world price”/community fixed-fee scheme to fund the development of Numpy: he wrote a big pile of documentation (the Numpy Book) and sold it until a certain total dollar amount had been reached, at which point the book became freely available. At Enthought, we earn consulting contracts based on our BSD-licensed Enthought Tool Suite and our involvement with the Numpy and Scipy projects.
BSD/LGPL does not imply that you will not make money, and GPL does not ensure that you do. The only way to ensure that you *do* make money is to explicitly dual license.
(Edited: as some have pointed out, dual licensing basically requires the use of the GPL with a commercial license, as BSD does not prohibit commercial use.)
I think there is a very good discussion to be had about how to commercialize the success of open source. Talented coders need to be compensated so they can afford to continue to innovate. Users should be free to use code however they wish, with no limitations on their freedoms, because code is ultimately a form of expression. But we need an interaction model that allows the expression of values and economic preferences without grounding certain values to zero, which is that traditional OSS licenses tend to do. As the practice of software development matures, we simply have to find a better economic model than the traditional Stallman-Gates bifurcation.
However, I think that choosing GPL or BSD is orthogonal to whether or not you feel your work is valuable; it is merely a way to define the kind of community you want around your project. If the community is filled with selfish, short-term opportunists, then protect your code and yourself with the GPL. If the community has a large, healthy contingent of commercial developers, then you’re only hurting yourself if you shut them out.
I recognize that in the scientific Python community, we’ve been extremely lucky to have developed the user base that we have, but I think that has largely been possible *because* we use the BSD license.