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.
______

Simon:

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).

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.

Ted Haeger
Director, Bungee Connect Developer Network
Bungee Labs

Rate this:

Like this:

LikeLoading...

Related

5 Responses

Hi Ted,Excellent response. I considered the “Affero” license for some time and concluded that it actually discouraged competition. A more powerful mechanism was the use of GPLv3 and trademarks. The “SaaS Loophole” turns out to be beneficial.I’ve commented more on this at the original post. The actual license structure we were planning was GPLv3 for the core engine + LGPL for the administration and connecting applications.

Ted – can you be more clear about this statement regarding GPLv3: “Is there a danger that small companies could replicate our offering? I don’t think that’s the case.”

Your business strategy seems to be solely around charging for the hosting. Why aren’t you worried that some small company will take your Bungee App Server and throw it up on EC2 and start undercutting you at $.03 per user-session/hour? Under GPL and AGPL that is allowed. You may feel this is acceptable risk, but the danger is there?

As a comparison, SugarCRM is a GPLv3 product. There is a lot of competition for hosting Sugar Community edition. Where SugarCRM appears to make ALL of their money is on upselling non-GPL features (professional, enterprise editions) on top of their GPL community edition.

It seems to make (A)GPLv3 work, you can’t open source the entire Bungee App Server?

@Peter Laird:
You’re right, that needs clarification. I think that Simon’s twin solution (reputation + trademarks) is a solid defense against small-time replicators. Additionally, it would be a big challenge for replicators to keep up with a company using an open source SaaS delivery model, because the maintaining company can set a fast pace of delivering features. (I describe this somewhat in my post “Feature Updates in the SaaS World.” Although I focus there more on SaaS versus traditional delivery models, I think it would apply to copycat services. They would be seen constantly as behind the curve. Maybe apps that are not under active development would be okay to host on a copycat platform, but for such apps we need to assume that the app requires long term persistence. That raises the question of whether you want to rely on the persistence of a startup replicating another startup.) Where was I? Oh, yeah…so, I realize the risk is there, but I think that small replicants would validate Bungee Labs more than undercut.
But really, when I wrote “I don’t think that’s the case,” I was thinking about danger relative to the threat of a large player coming in and doing the same. That’s so much larger a risk that the small player threat seems irrelevant to me.

Your SugarCRM example works to an extent. It may be that Bungee Labs may eventually need to have an expert services arm. If that hypothetical ever came about, I should hope that it would exhibit excellence. In a past company, I found time and again that the professional services arm guilty of engagement quotes that extended into suspiciously long periods and high costs. (That has nothing to do with Sugar’s practice, which I know nothing about.)

Holding back a piece of the stack would also be a possible play, although whatever platform provider did so would need to have a good way of explaining that decision. Canonical was eventually pressured to start opening LaunchPad, for example.

[…] a post this morning providing his thoughts on the some the FOSS options available to Bungee Labs Ted wrote back responding to Simon sharing his point of view Then Simon responded to Ted All three posts (and more to come no doubt) […]