Update 2012-04-21: Meteor has switched to the permissive MIT license.
Meteor made a big splash this week. Check out their screencast if you haven’t already. For “real-time” web applications it really seems to simplify things a whole lot. The team behind it seems plenty experienced and they are building a business on Meteor by going with the GPL/commercial dual-license approach made popular by MySQL and Trolltech/Qt. The basic idea is that the source code is publicly available for people to look at and modify and that it costs nothing to use as long as you’re building a GPL application with it and give out your source code too. Alternatively, it can be licensed commercially like any other proprietary product. Dual-licensing is not the only way to monetize open source development - a popular alternative is to offer support, training and consulting, like 10gen does for mongoDB. Anyways, I think Meteor is plenty cool and I wish them the best of luck!
The web development community hasn’t really taken GPL libraries/frameworks to heart, neither client- nor server side. Let me elaborate on that.
Let’s check out some server-side frameworks in other languages. Rails, Django, Tornado, Play, the list goes on. Permissive.
What about the data stores? Server-side code typically connects with those through client/driver libraries of some sort. PostgreSQL, CouchDB, Redis, Riak, Cassandra, Memcached, SQLite – all permissive licenses. MongoDB is AGPL but the client is permissive (Apache) so there’s no copyleft affecting your program that talks to the DB. MySQL is more complex. After all it was the product that defined dual-licensing so that’s not entirely unexpected. The DB itself is GPL, but the client library is LGPL in really old versions, GPL with a FLOSS exception in versions prior to 5.1.55 and plain GPL in recent versions released by Oracle. Oracle also provides a PHP client library under the PHP license. You can also acquire a commercial license of MySQL, with a non-copyleft client library. So whether you can write a proprietary program that talks to MySQL, depends. That’s a whole lot of babbling about data stores licenses, pardon.
Not everything is permissive of course. A good amount of projects use limited-copyleft licenses such as the MPL, EPL and LGPL. The intent is almost always to allow for proprietary usage of the library/framework/program, but to mandate that modifications and additions to the project itself get contributed back, to various extents. EPL is particularly common in Java-camps (so is the permissive Apache 2.0 mentioned earlier). Mozilla use MPL for most (all?) of their stuff, and it also happens to be the most permissive of the three.
And then we have the regular copyleft licenses, most notably the GPL, which isn’t that popular when it comes to web development libraries and frameworks. Sencha’s ExtJS framework is GPL/commercial dual-licensed. Many avoid it for that reason, and for those there are similar projects available under permissive licenses. Wordpress is a another GPL project that is very popular.
If we start looking under the hood, there’s a good amount of permissive licensing going on in other parts of the web stack. PHP, Ruby, Python, Apache HTTPD and nginx are all permissive. There’s also a good amount of GPL and LGPL, most notably the Linux kernel and the GNU userland.
Let’s focus again on client- and server side web development libraries/frameworks. By far and large, the web developer community seems to prefer permissive licenses for that. Permissive licenses are proprietary-friendly, and many web developers write proprietary programs for a living. Many also don’t have a problem with giving out their code for others to use however they wish, save for some attribution. Most importantly, many consider the idea of proprietary programs and services to be fine, sound, ethical and all that. It’s also fairly obvious that permissive OSS projects can attract huge contributions even without any help from a license that mandates it. Imagine Node.js or Rails being GPL. Would they have received more or less contributions, you think?
I hope you won’t blame me for calling web developers “rewrite-happy”. Heck, the entire programmer population is, to some extent. Someone takes the ideas of a library or framework and rewrites it in another language. Someone else rewrites it from scratch just because he/she (hen!) was unhappy with a particular design decision. Competing frameworks overlap. Just look at the throne of JS conference. Now this is both good and bad. Good in the sense that it’s very evolutionary and that it constantly pushes innovation forward. Bad when yet another author loses yet another potential contributor to yet another similar-looking 0-day friendly competitor. But it’s mostly good.
The publicly available Meteor code base is licensed as GPL (v2). Any application you write using it - definitively the client part and quite likely the server part as well (due to Meteor’s tightly intertwined client and server architecture) - any such application must be released under GPL compatible terms. I.e. you must hand out the source code, and no you can’t obfuscate it. If you want to write a proprietary program then you need to have a discussion with the Meteor team about how to acquire a commercial license. Combining rewrite-happy with a preference for permissive licenses, I think it’s reasonable to expect existing project to adapt a few of Meteor’s core features and design ideas, and new ones popping up as friendly competitors. Hardly shocking.
The copyleft (viral, contaminating, whatever you want to call it) aspect of GPL is tricky. Take MongoDB as an example. Meteor uses it by importing the node-mongodb-native package (
require('mongodb')). That one is Apache 2.0 licensed, which is a permissive license that happens not to be compatible with Meteor’s GPL (v2) license, at least not according to the FSF. Tricky. Dependency chains, bindings between JS ↔ C and RPC makes it trickier even. I wouldn’t be surprised to see Meteor change to a GPL + a-bunch-of-OSS-exceptions license similar to what Qt and MySQL used to have, to avoid issues like this.
I’m curious to find out to what extent the Meteor ecosystem will attract outside contributors, and to what extent people will start using the GPL version of Meteor in their projects (accepting the copyleft). Copyleft code grows from one project to another because it must or else the license screams VIOLATION. Permissive code grows from one project to another by culture and an honor system. It’s like, I used all this code and all that was required by me was a tiny bit of attribution (if that even) - I wasn’t limited in terms of how to combine it with other code. When I choose to pitch in something in return, it’s only fair of me to be permissive too. That’s how I perceive the mindset of the web development community at large.
And yeah, I used a sensational title. Tricky.
Update 2012-04-21: Meteor has switched to the permissive MIT license.
Follow me on Twitter