ailon's DevBlog: Development related stuff in my life

GPL/Commercial Dual Licensing Is Evil For Libraries

12/27/2011 6:12:00 PM

I’ve listened to Hanselminutes on Kendo UI a couple of days ago. It was a great podcast as usual and, even though I haven’t personally used it yet, I’ve heard good things about the Kendo UI framework. What I haven’t noticed before and what I’ve heard on the show was that Kendo UI is released under a dual GPL/Commercial license.

I used to run a dual-licensed GPL/commercial product from 2003 and decided to never go that road again. The decision isn’t new, but I figured I’ve never put the reasoning in writing. So here it is. Here’s why I think GPL/commercial dual licensing is bad for your libraries (from the developers/publishers perspective).

Disclaimer: IANAL (I am not a lawyer). So all of this is just my point of view on the issue.

Why GPL/Commercial in the first place?

This was our rationale for SPAW Editor and, from what I’ve heard on the podcast, Telerik’s rationale was pretty much the same. We didn’t mind (and even wanted) open source projects using our library for free. That sounded great both from “good karma” perspective and free word of mouth promotion it was supposed to generate. On the other hand, we didn’t create the library out of pure love for coding and expected to support it by selling it to commercial customers. GPL looked like an easy solution for our needs. It allowed us to release the code to be used by open source projects and prohibited its use in the closed source projects. Or at least that’s what we thought at that time.

Unfortunately even though it is partially true, partially is a key word here and it has quite a few caveats.

Problems with GPL/Commercial licensing

  • GPLed version can only be used in GPL-compatible projects.
    GPL is contagious. Once you use a GPL library in your project, you can only distribute it under GPL. So we weren’t serving non-GPL OSS projects and there are lots of them.
  • Your product is not really Open Source.
    As long as you are the only contributing party you can re-license your code in any way you like. Once there are other contributors to your GPL project, their contributions are covered by GPL and you technically loose rights to dual-license it. Obviously you can work around this with some legal work, but that’s an extra barrier to entry by contributors. So I’m pretty sure that, even though Todd Anglin stated on the podcast that they are looking into enabling contributions, this will never materialize.
  • GPL is confusing. Especially in our (library/framework) cases.
    GPL FAQ is 35 printed pages long. When you are building your business on top of GPL you can manage to read and understand it. When you just want to use a library (which has competitors with simpler licenses) – you wouldn’t bother.
  • It creates a lot of “legal” support overhead.
    Following on the previous bullet point, the most frequent type of question we were getting was “I want to use your library in Scenario X. Can I use it for free?”. We used to have a question like that in our FAQ (it is not there now since we stopped offering commercial license), but it didn’t help. Every situation is slightly unique and your users don’t have enough time and/or willingness to figure it out on their own. So they delegate it to you.
  • You are not getting as much viral promotion as you would’ve with non-restrictive open source license like BSD, MIT or MsPL.
    Just because fewer OSS projects can use your product.
  • You are not monetizing who you wanted to monetize.
    GPL covers distribution. If there’s no distribution involved everyone can use your library for free “under GPL”. So if Microsoft or, say, Google build their own sites in-house they can use your product for free.

These are the issues I’ve experienced with the model that I can think of from the top of my head. I bet there are other things too.

Is there a better way?

Provided that our objective hasn’t changed and we want to support non-commercial and/or OSS initiatives with a free product and monetize commercial users, I’ve seen 2 approaches that work better, in my opinion, than GPL/commercial dual-licensing.

  1. Core product under (more) permissive license, commercial extras.
    This is the approach used by the most popular web WYSIWYG editor (and SPAW Editor’s competitor at the time) – TineMCE among other projects. I think it was one of the reasons (probably not THE reason, but still) why they “beat” us. The core library is released under LGPL or totally permissive licenses (BSD, etc.) and you make money on extras that are not required, but have a wide enough appeal to generate revenue.
  2. Linkware/Commercial dual-licensing.
    This is the approach we use with most of the amCharts products (and, no, I didn’t come up with the idea). This would probably only work for more elaborate UI libraries (like charts). The idea is that you give away your library for free to anyone with only caveat that it includes a link back to your site. Non-profit projects wouldn’t mind it in exchange for a great product, and commercial users probably would mind it and buy a license (or they wouldn’t mind and you still get advertising from them).

That is basically it. Let me know if I forgot something or if you think I’m totally wrong. You can do it either here in the comments or on twitter.

P.S.: feel free to follow me even if you don’t have anything to say on the subject ;)

Tags: ,

Choose Your Open Source License Wisely and Stick to It

5/19/2008 5:50:48 PM

os_main Recently there was quite a storm in web development community about a move by popular JavaScript framework ExtJS. They've changed their licensing scheme from LGPL/commercial to GPL/commercial. And as this quite radical post by Paul Duncan title "Don't Use ExtJS" suggests earlier Ext was released under very permissive BSD license.

I've never used ExtJS and don't know much about it except the name and that it's quite popular, but the controversy concerns me as I'm a lead developer of an open source project released under the same GPL/commercial scheme. I assume some (or maybe even most) of the ExtJS attackers wouldn't call my project open source as they refuse to call ExtJS open source now.

ExtJS's situation is not as straightforward as mine. In 5 years since the first public SPAW Editor release we've never changed the licensing scheme. And we don't use any third party code (maybe some small parts from Mozilla's or Microsoft's documentation). But the fact that I'll be attacked if I ever decide to change the scheme (not that I plan to) saddens me.

The Root of all Evil

From my perspective the problem arises when people starting open source projects don't have a vision of what they are trying to achieve in the long run. This is very understandable cause sometimes you think you just have a small library on your hands that you would like to share with the world. In the early days of project's life you are totally satisfied by positive feedback from your users and don't think of anything else. But as days go by supporting the project becomes a routine, you get less and less satisfaction from working on it and unless you are a total programming junky you gradually loose all interest. At this point you either have to find a new "owner" for the project, let it die or start getting financial motivation.

Getting Paid for Open Source

Getting paid for your open source project is a tricky thing. Getting small donations from lots of users doesn't work as far as I can tell. You might get lucky and get a couple of major donations but I don't think that you can get those by placing a passive "Donate" button on your site. Getting VC money for your small-to-medium open source project is way too complicated for small development teams and not everyone dreams of selling their freedom and making their "baby" just another full-time job. Selling support for your project is a tricky thing too. I believe that open source project owners should provide support to all the users and not only those who paid for it.

All of the above methods could work but require quite aggressive "sales" activities to succeed. So, this leaves us (commercially passive OS developers) pretty much with the only option - dual licensing.

It seems that differentiation between who should be able to use your code under open source license and who should buy a commercial one is pretty simple:

  • open source projects and non-commercial projects should be able to get your product under the OS license;
  • commercial projects should buy a commercial license.

The problem is that there's no such standard open source license that let's you implement the above scheme. GPL is closest: it allows usage in other GPL projects and prohibits distribution in closed source and other non-GPL compatible open source projects. The last part is the cause of all the issues developers of non-GPL open source projects have with GPL and in this case with ExtJS. But unfortunately I'm not aware of any other open source license that comes closer to implementing this fairest (in my opinion) paradigm. Or did I miss some new advancements in those five years since I was actively looking for a licensing concept for SPAW?

Moral of the Story

I understand that I'm not a true open source developer and most likely neither is Jack Slocum (lead Ext developer) but I hope that by releasing my code under GPL I contributed my share to the community. I was lucky to think about such situation before releasing my software and though I understand Jack's motivation I agree with "whiners" that changing licenses as you go sucks. Though I can't see why those complaining can't fork from an earlier LGPLed or even BSDed ExtJS version and build a "truly open source" alternative.

So, the point is that it's very important to understand what are you trying to achieve by releasing your software as open source. If your goal is to make the world a better place, or you want to get community credibility to get paid more in the future, or you have some "alternative" business plan - go with permissive open source licenses like BSD, MIT, etc. But if you feel that you'll be upset that someone profits from your work while you're buying junk food with your last pocket change do yourself a favor and think about this before you release anything.

In any case I think it's important to make a wise, well thought out decision and stick to it. In my opinion it's better to have fewer but satisfied users then lots of unhappy ones.

kick it on DotNetKicks.com

Tags:

Copyright © 2003 - 2017 Alan Mendelevich
Powered by BlogEngine.NET 2.5.0.6