My four posts on Open-Core Licensing:
- Open Core Licensing defined (AUGUST 29, 2008)
- New and Improved Open Core, with AGPL (FEBRUARY 2, 2009)
- Open Core: the New Standard in Commercial Models (MARCH 2, 2009)
- Variants on Open Core (March 25, 2009)
===============
A valuable open source product, a vibrant community, and the right licensing strategy are three keys to the success of a commercial open source software company. This post is a follow-up to my previous blog about the open-core licensing business model, and I address these points around the topic:
- How do you balance features between the commercial and open source versions?
- How do you build a successful community?
- What about the Application Service Provider (ASP) loophole?
Some Background
Last August, I proposed the name “open-core licensing” for a specific commercial open source business model which appears to be an emerging standard and acceptable in premise by corporate buyers such as CTOs. In this business model, the core technology is licensed under an OSI approved license (typically GPL), and a commercial open source vendor that owns the intellectual property can also offer a commercial license that covers both that core technology as well as premium add-on features. In other words, the term “open-core licensing” was a proposed business model name for a specific type of dual licensing or twin licensing (i.e., if you own or control all the copyrights, you can issue a commercial license with exactly the same bits as the GPL version; it’s dual or twin licensing, but it’s not open-core licensing). This specific business model name was picked up by Matt Aslett of The 451 Group and open source industry observers such as Dave Rosenberg and Savio Rodrigues as an apparently increasingly recognized way to scale a commercial open source business model. Perhaps it is becoming even more accepted now than the previously presumed superior business model of “services only.” While there are certainly vendors out there that do not own the core copyrights of the product but provide commercial extensions, there are some benefits to owning the core copyrights, and that will be covered in a separate blog.
Achieving Balance Between Open Source and Commercially Licensed Versions
It’s a great question and still being posed: “how do you achieve balance between open source and commercial versions?” I think the answer is not a generic, precisely defined method for all vendors but rather specific to each vendor. But the overarching theme to the answer is simply put: make sure the value of the open source edition is compelling enough for broad adoption of the open source product. So, if your open source product is not being widely adopted or not being adopted quickly enough, you probably need to include more of the commercial features in the open source version. For example, keeping a pulse on your open source download rate and forums usage are probably both a good barometer of value in the open source version.
How Do You Build A Successful Community?
There are a lot of good overviews out there (Stormy Peters, Chris Brogan, Connie Bensen / Jeremiah Owyang, and John Lilly). Matthias Stürmer provided a detailed analysis in 2005. I think there are some other good discussions on the topic out there. Do you have further suggestions?
The ASP Loophole
Although GPL is not the choice license of developers for everything (e.g., many libraries), it is enjoys wide adoption, and it’s increasingly the license of choice amongst commercial open source software vendors. I propose that using the GNU Affero GPL v3 license as the specific type of GPL with the open-core licensing business model seems to be the next logical step on the path for commercial open source vendor business model evolution.
The problem with GPL v2 and v3, in the view of many commercial open source vendors, is that ASPs such as Google can profit quite heavily from GPL v2 and v3 open source efforts while not contributing back to those open source projects. Of course in a large enterprise, there is quite a grey area in the use of GPL, and a bank illustrates the case. A company like Citigroup may use GPL software internally, respecting the GPL license, but some of those systems which rely on GPL code may eventually be exposed to people outside of Citigroup, i.e., the ASP loophole. Does this violate the GPL v2? While a company such as Google would probably say “no,” most commercial open source vendors say, “yes.”
While providing many refinements over GPL v2 (see table) and pleasing companies such as Google and even Red Hat, GPL v3 received a tepid response from some commercial open source vendors due to the omission of the Affero clause which addressed the ASP loophole. Perhaps the most outspoken critic of GPL v3, Fabrizio Capbianco, CEO of Funambol, wrote:
The provision is not there. Gone. They dropped the ball. Actually, it has been made very clear that the ASP loophole is not a loophole anymore. It is perfectly fine to change GPLv3 software and offer it to the public as a service, without returning the changes to the community.
Since GPL v3’s release, more than 3,000 projects adopted it, and the ASP loophole was addressed with a new license called GNU Affero GPL v3 (AGPL). Noted open source legal authority Mark Radcliffe wrote, “The AGPL includes a provision requiring that companies providing services over a network make the source code available to users of the services (just as if the companies had distributed a copy of the software under the GPLv3) based on the well known "Affero" modification to the GPLv2.”
But Savio Rodrigues ponders whether the Affero clause is really necessary when a large company like Facebook contributes back code, even when it is not required to do so under a permissive license. My response in the comment section to his blog is basically, “isn’t that simply wishful thinking that all large companies will behave the same?”
I believe a comment by jrpenning on Matt Asay’s blog, points towards the right solution:
I think we're closing in on an optimal model. The AGPL tries to correct something that needed correction, but seems to be a bit too far on the other side. Dual licensing with an AGPL base would be a move back toward the center, where hopefully the optimum lies.
Therefore, a “best of all worlds” solution for commercial open source vendors is to use the open-core licensing business model with GNU Affero v3 as the open source license for the core technology.
When the AGPL license is combined with open-core licensing, software vendors that own their intellectual property are able to have their cake and eat it too. And commercial open source vendors, customers, and the open source community all have solid choices and preserve freedom.
While licensors should certainly be careful about license compatibility, I think AGPL v3 is the right move instead of GPL v3. Readers may presume that a product licensed under AGPL must be designed for SaaS. I propose that products for GPL consideration whose use case are 100% on-premise today but could eventually be used in a networked/web situation should be licensed under AGPL immediately in anticipation of the networked situations so that the licensor is protected. Therefore, up until the product is exposed publicly, GPL v3 conditions apply, and the Affero (ASP clause) is not pertinent. If our recent experience with web, internet, and other new technologies has taught us anything, it's that we cannot predict how software will be used.
That’s how I see things, but I am very curious to know of others’ opinions. In particular, I am curious to know about corporate adoption of GPL v3 and acceptance or criticisms of AGPL v3 – both at the executive and developer level. If corporate stakeholders object to AGPL v3, I would like to understand why. My guess is, as expressed by a variety of people in this 2007 blog, they generally don’t care about licensing. They simply want value and the right products for the right job, and they are willing to pay for the value entailed when required. And even if it’s really the developers, rather than executives, that are actually making the choices of open source products and their corresponding licenses in the bottom-up adoption, an open-core licensing model allows acquisition of a commercial license if that is desired.
================
****Special thanks to Matt Dahlman and Sherman Wood for their edits and input to this post.
==============
================
Check out my other posts on Open-Core Licensing:
- Open Core Licensing defined (AUG08)
- Open Core: the New Standard in Commercial Models (MAR09)
- Variants on Open Core (APR09)
Comments