This interesting comment I pulled though from his post was the following:
Matt is on the record repeatedly promoting the GPL as the best license, in all circumstances, for businesses that build and distribute software. I think he's flat wrong,...
Now the GPL is one license model, but there are two other common open source licenses, the BSD and Mozilla Public License. There are dozens of license that are shades of grey between these three license, but I have always felt that these three licenses represent the basic license and business models in open source.
All of the licenses give the option for a developer to make money off support. Support is the easiest business model, but it carries a Catch-22. For open source to be used is needs to be easy to install and easy to use. This makes it difficult to make money on supporting it.
Non-re-occurring engineering is another method for making money on any open source product. Once you write something, someone will come along who needs it to do "just one more thing". Most of the time as and engineer you just end up doing these features since it makes sense for the product. You do them though based on the order of your own needs and how these are related to your own roadmap. People will pay to jump their feature to the front of the development queue. This is why you can make money on NRE.
But what do the different licenses bring to the table?
The GPL gives you the ability to dual license. There are closed source companies that will want to cut corners in their own development time. They want to incorporate libraries to get to market more quickly. If you own your IP then you can sell them this right. Owning your own IP is a tricky business though, since it makes it much harder to take patches from the outside world, or use other open source components to develop your software more quickly. This is a very double edged sword.
The BSD license gives you ubiquity. Anyone can use it for whatever they want. This means little ability to sell it, but the ubiquity will buy you a lot of users. More possibility for NRE, more possibility for support, and it gets your name everywhere. It is great advertising and represents the type of marketing that companies would die for. It also means, I believe, a much lower chance of building a large organization. For engineers who want to put together a business around just themselves, with no marketing or sales, I've noticed that this works pretty well (I saw Tim O'Reilly once comment that he was going to put together a blog entry about people who put together lifestyle businesses, I've been eagerly waiting to see what his thoughts were on this topic).
The Mozilla Public License, aka the MPL, is the hardest license I think to understand. You aren't going to do dual licensing with it, and companies that use code that make use of this license are still restricted, some what, with what they can do with your work. With the MPL you force companies to provide their changes to your code to give those changes back to you. I think this is great from a standpoint that you learn how people use and modify your product. I doubt though that the code is often very useful. So the advantage to a developer using this license is free R&D.
To date I have used all of the licenses above except for the MPL, and have found them useful for different reasons. I normally follow the license of the project I am writing code around (and if I write just a stand alone library, I go for the BSD since I find value in ubiquity). I don't think any single one license is a catch all solution for all code bases.
A few years ago I wrote a rather awful chapter for Chris's "Open Source Voices" that never got published. I never could finish it, and I could never quite find the right words. Writing that article made me really start thinking about different open source licenses though. Not enough has been written on the reasons behind the different open source licenses, and I think there are some fascinating studies that economists miss by not looking at this fundamental issue found in different open source projects.