As I am involved in Bungee Labs’ planning for how we might open the platform, I found good insight and value in Simon’s thoughts and suggestions. However, I also think that Simon may underestimate the importance of Free Software licenses for platform providers, or may not be aware of the significance of one of the Free Software Foundation‘s current licenses, the GNU Affero General Public License, version 3.
Here is my response to Simon regarding his post.
The emergence of hosted development platforms will raise many questions for FOSS enthusiasts. I work at Bungee Labs, and I have been speaking on the topic of FOSS in the age of hosted development platforms quite a bit lately. (Socal Linux Expo, LugRadio Live USA, LinuxFest Northwest).
The presentation that I have been giving is titled “Freedom in the Cloud: Development Platforms meet Software as a Service.” [lugradio live video] One of the topics that I naturally must address is the question of when and how Bungee Labs would open Bungee Connect.
You state: “Let’s now hypothesize that Bungee Labs open sources their environment under GPLv3. Now rather than giving away their competitive advantage, this would instead be a bold and risky move (all innovations are) to capture a much larger market.”
Personally, I think that GPLv3 is the wrong license for freeing any SaaS or PaaS offering. The Free Software Foundation has a better license for this purpose.
GPLv3 is inadequate because it does not mandate that modifications that others make be opened. Originally, GPLv3 was planned to close up the “SaaS Loophole” (a.k.a. the “ASP Loophole”) in GPLv2. However, as I understand it, several large companies pressured the FSF to remove the key clause that would have closed the loophole.
What is the loophole? It’s this: if you take free software and offer it as a hosted service, then you are not conveying the software, and are therefore not obligated to reciprocate your modifications to the original code. In the context of service providers, GPLv3 is effectively the same as the BSD license. Many companies, Google among them, live inside this loophole. (For now, Bungee Labs is also in that camp.) Some remain there deliberately. Others are in it simply as a matter of course…that is, where they are in their business development process.
Are such companies behaving unethically? Not according to the FSF’s most recent version of the GPL. Perhaps the argument could have been made in the age of GPLv2 that the SaaS Loophole was an oversight, but now that GPLv3 has the loophole by design, it’s really no longer a loophole. The latest version of the license supports the practice. (And just to be clear, I am not advocating this for Bungee Connect.)
Let’s extrapolate on your hypothetical scenario. Say Bungee Labs opens Bungee Connect under GPLv3. Is there a danger that small companies could replicate our offering? I don’t think that’s the case. But could a well-funded company do the same, fork the code, and then fund an engineering team to outpace the original inventors? This is where your suggested use of reputation and trademarks would be a necessary strategic component in the overall defensive calculus that a SaaS or PaaS provider must consider. However, I think you may have discarded the importance of FOSS license choice too quickly.
The Free Software Foundation also provides the GNU Afferro General Public License version 3, or AGPLv3. AGPLv3 specifically closes the SaaS loophole. Instead of being triggered by conveying the software, AGPLv3 is triggered by accessing the service. This helps to reduce the risk that a company could not branch the code and then out-engineer the originators, as the vulture company would be obligated to share-alike terms with their derivations.
With all the intricacies of FOSS licenses, there certainly is more to discuss in this area. I have been telling my audiences that among the many initiatives that Bungee Labs is working on, the plan for opening the platform is among them. My hope is that within a few months (pending on a couple technical projects we are working to complete), we will be unveiling first a roadmap to what we intend to open (and when), and shortly thereafter begin delivering on that roadmap by opening components according to the announced plan. Perhaps the license discussion I provide above reveals how seriously we are approaching the issue.
Has Bungee Labs made any moves toward openness yet? Definitely. Last month, we announced two community source licenses. The first makes source code for Bungee Application Server available to Bungee Labs customers. The second is a Research and Development Only license, allowing anyone to study the Bungee Application Server source code.
If you have more that you would like to share or discuss, you now have both my blog URL and my email. Thanks again for publishing some of your thoughts on the matter.
Director, Bungee Connect Developer Network