Open Source Licensing Nirvana

Over the last weeks Alfresco, Sonatype and WaveMaker made their own decisions about licensing.

Alfresco went LGPL, Sonatype – a company with a strong Apache background – for the very first time decided to release some code under GPL, while WaveMaker dumping the AGPL in favor of Apache.

Let’s have a closer look at how – and if – these changes reflect new business directions.

Alfresco.

Alfresco’s CTO John Newton,  in an email exchange answered few questions around the last license change (why, evidences justifying the choice, trade-off between costs and returns).

I believe this is our “SQL” moment. CMIS will standardize all the major ECM platforms in a huge industry. Independent software vendors will start to build content applications knowing that they will run on SharePoint, FileNet, Documentum, Open Text, Lotus, etc. This is exactly what happened in the database industry and when Java appeared. If Alfresco is available for free and it doesn’t affect their licensing, then those developers should develop on Alfresco.

How do I know this? It is not based upon survey, but previous experience and anecdotal information. MySQL became the platform choice of development since 2001. JBoss became the platform of choice for J2EE – and we were one of those building upon it. Weblogic got started by providing a free platform originally. We know that there are people out there today who are using Alfresco because it is free, but not making their code available as GPL as the GPL states.

You are right that it is not a cost-free operation. The actual change is more annoying than anything else. However, we do have an OEM business based upon the dual license. Our bet is that the increase in application pull into enterprises through will more than compensate for any lost OEM business. So far the comments we have receive indicates that this is a good move.

Alfresco’s change reflects an interest in reaching a broader user-base through System Integrators offering solutions based on the community edition. Reading the differences between the community and the enterprise version is clear that users looking for enterprise grade software (QA, upgrade and maintenance, etc) will then move to the enterprise edition.

John mentions the possibility that in a future Alfresco may go Apache or BSD, but this is not to be confused with the idea to embrace a more collaborative approach to code production.

Sonatype.

Sonatype’s decision to throw over the wall some GPL code – namely the Nexus small-footprint repository manager – may sounds odd keeping in mind their strong Apache background (and Eclipse too).

Reading Sonatype blog entry on the subject is self-evident that the decision has been carefully weighted, and I warmly suggest anyone interested in this matter to read it all. Take aways from their decision:

  • a clear need to protect their investment and allow the company to profit from them;
  • the will to share code and (if possible) code production;
  • the will to not prevent private enhancements;
  • be pragmatic avoiding any dogmatic approach.

WaveMaker.

Apparently the only reaction from developers were questions about the AGPL, but when the company’s goal is to maximize the dimension of your community (of users) making developers’ life easier is a plus.

Decisions about open source licensing are about license compatibility, business strategy and cost structure.

While license compatibility is a must (see Alfresco’s decision to postpone the move to Apache or BSD), the impact on the different communities should be carefully assessed. Developers, ISVs and SIs, Partners and Customers ‘communites’ have different interests.

Peraphs developers don’t care too much about licensing, and requiring them to put as less effort as possible to understand is key.

ISVs and SIs do care, because their customers do, while OEMs facing end-consumers may care less, as seen in the consumer electronics market. ISVs and SIs tend to like the most permissive license, especially if they need to integrate open source applications with proprietary software. Double licensing maybe not welcome by them, unless partner program’s benefits outweights the costs. Of course open source vendors can adjust these parameters over time.

Partners maybe interested in a license allowing them to create proprietary add-ons, double-licensing may suit their needs if the business deriving from the community version is not relevant or prohibited.

Customers may enjoy license schemes that favor external contributions, reducing the vendor lock-in and fostering innovation.

Changing license is always (legally) possible, I agree that changing for a more restrictive one should be avoided.

Related Posts