Quickies #5: GPL or BSD?
Now enjoying my status as a sage of the industry, which is to say I am older than 20, but alas, not a billionaire, God fuck-it; people are all the time asking me for nuggets of wisdom from my vast experience at the top.
Quickies from MF: #5 GPL or BSD?
D.B writes in. "Marc, I am about to launch a project in open source, we have invested a good man year in developing it and I want to know what license I should use for the project."
Answer. D, you can't imagine how many versions of this question I have seen over time. It is also a polarizing question. People care about their licenses and many a flame war have resulted from passionate debate about the benefits of each.
The quick answer however is that IT DOESN'T REALLY MATTER.
The longer answer is that it doesn't really matter because the ultimate license scheme for OSS is still RHEL/Fedora: a proprietary distribution of OSS software. It doesn't matter if the software inside is GPL/BSD or whatever. Realistically speaking however, RHEL/FEDORA is not an option for young projects, this is only viable for established products and may snuff your growth in the early stages.
Historically, the bigger projects to drive commercialization of OSS have been based on GPL/LGPL, MySQL, Linux, JBoss. It may be because GPL and derivates offer you a measure of protection by requiring reciprocity. Your user community, specifically the ISV's, either contribute code back or take out a dual license to avoid the requirements of the GPL. With dual licensing you track your ISV community from the beginning and quickly build revenue streams. It is a good thing if you intend to go professional with your project.
BSD derivatives on the other hand, provide the competition with the right to cherry pick your stuff and not give anything back, not money, not code. Think about how OSX has displaced Linux on the desktop by using its BSD variants. A proprietary vendor got the monetary benefit of the work of OSS legions, not the OSS legions. As a general rule of thumb, reciprocal licenses (GPL) help the developer make a living, academic licenses (BSD) help the competing vendor.
At the end of the day the argument is also one of philosophical taste. I say the GPL is great because it enables individual developers to grow businesses fast on dual licensing. Others may prefer the more permissive approach of letting anyone do whatever they please with their code.
But again, I have seen many a brother and sister get fanatical about these issues, and waste energy on the wrong discussions when truly, they are important but not paramount. Good code will prevail.
MF
Quickies from MF: #5 GPL or BSD?
D.B writes in. "Marc, I am about to launch a project in open source, we have invested a good man year in developing it and I want to know what license I should use for the project."
Answer. D, you can't imagine how many versions of this question I have seen over time. It is also a polarizing question. People care about their licenses and many a flame war have resulted from passionate debate about the benefits of each.
The quick answer however is that IT DOESN'T REALLY MATTER.
The longer answer is that it doesn't really matter because the ultimate license scheme for OSS is still RHEL/Fedora: a proprietary distribution of OSS software. It doesn't matter if the software inside is GPL/BSD or whatever. Realistically speaking however, RHEL/FEDORA is not an option for young projects, this is only viable for established products and may snuff your growth in the early stages.
Historically, the bigger projects to drive commercialization of OSS have been based on GPL/LGPL, MySQL, Linux, JBoss. It may be because GPL and derivates offer you a measure of protection by requiring reciprocity. Your user community, specifically the ISV's, either contribute code back or take out a dual license to avoid the requirements of the GPL. With dual licensing you track your ISV community from the beginning and quickly build revenue streams. It is a good thing if you intend to go professional with your project.
BSD derivatives on the other hand, provide the competition with the right to cherry pick your stuff and not give anything back, not money, not code. Think about how OSX has displaced Linux on the desktop by using its BSD variants. A proprietary vendor got the monetary benefit of the work of OSS legions, not the OSS legions. As a general rule of thumb, reciprocal licenses (GPL) help the developer make a living, academic licenses (BSD) help the competing vendor.
At the end of the day the argument is also one of philosophical taste. I say the GPL is great because it enables individual developers to grow businesses fast on dual licensing. Others may prefer the more permissive approach of letting anyone do whatever they please with their code.
But again, I have seen many a brother and sister get fanatical about these issues, and waste energy on the wrong discussions when truly, they are important but not paramount. Good code will prevail.
MF
Comments
You are giving this hard-earned knowledge away. You should charge for it! Possibly go on speaking tours. What kind of businessperson gives knowledge away?
You are right. I should charge for this stuff. But then again, when I started giving away JBoss people some folks were saying "why"... the answer was "because I can"
I would probably agree with you, if you don't care to every monetize your code then public domain is even a better choice. I like the cleanliness of some of the Creative commons licenses: if you are commercial, you pay. Makes sense. In the GPL we achieve this effect indirectly by triggering GPL on redistribution, it is a technicality and the goal is not explicit.
I assume Burke not Gates :)
Precisely. The brand comes from good code and community, and community usually follows good code but not always :) The arguments that BSD or GPL increase your community appeal or adoption to me are theoretical hogwash. In practice you get massive adoption of GPL/LGPL and BSD.
And if that is the case, that the license don't help or hinder your adoption, depending on your type of library, you might as well derive a revenue from the redistribution.
Starving poet was never my thing.
Other than that, though, great insight (as usual).
Last I checked Alfresco was a classical on-ramp model. You offer additional bits under proprietary licenses. This is different from "the same bits under proprietary licenses".
Of course, feel free to correct me if this is not factual.
On-ramp models are of course very beneficial for young companies because they supplement revenues from the get go.
johnmwillis.com
I'm on a team trying to change that. My team is trying to push the business to using jboss as opposed to weblogic and websphere but unless the vendor has easy access to the binaries this makes using jboss less likely than it already is, which is pretty low.
I was very upset to learn about the change in the model for jboss about a year ago because I knew it would make it even harder for new jboss projects to get started. Unless it is extremely easy to build from source or a centos-like project is setup that offers binaries for it I see the new model for jboss 5 keeping jboss' usage at my company down at the bottom. Way behind the usage for websphere and weblogic.
Maybe the new model is the right move overall but it may have caused jboss at my company to end up DOA.