As exciting as Meteor is (VERY!), their approach to licensing kills it for me. The products I am working on cannot be licensed under GPL for a large number of r

As exciting as Meteor is (VERY!), their approach to licensing kills it for me. The products I am working on cannot be licensed under GPL for a large number of reasons, and their "talk to us and we'll see what we can do" policy puts too much risk into my business plan. At the early stage of product development, I don't necessarily know the finer points of how my revenue model will work. If there's a fixed fee for a commercial Meteor license, then I can put that into my business plan, see what kind of impact it has under different scenarios, and make a judgement call. But a "let's discuss your revenue model and see what makes sense" approach simply can't happen during the earliest stages of product development. Which means that basing my product around Meteor would introduce a potentially catastrophic risk into my business, should their licensing terms turn out to be too onerous, once that conversation can finally be had. So, with considerable regret -- because it looks awesome -- Meteor is unusable to me. I'm certain that many other people are in the same boat. Its developers say that they've chosen this license because they want maximum contributions from the community. By seriously limiting the size of the community that can use Meteor, they've chosen the wrong way to do it. I would strongly urge them to reconsider their choice of licenses. The MPL[1] would probably be the most compatible with their aims, since it requires any modifications to the core Meteor components to remain open source, while allowing the inclusion of closed-source components without violating an aggressive copyleft. This is a constraint that I would be very happy to live with. Choosing between an agressive copyleft or whatever is behind the mystery curtain labeled "commercial license" is not. If the Meteor team wants to fix this, they can either: 1. Clearly state that they require a commercial license for commercial use, and state the price and terms of that license upfront (the Sencha approach). Or, better yet: 2. Switch to a license such as MPL, BSD, or MIT. The former will allow commercial developers like myself to begin adopting Meteor; the latter is guaranteed to produce a much more robust open-source community around it. If Meteor is to become the next Rails, then that's what it needs to do. Barring this, I'll just wait for other enterprising developers to take the Meteor concept and re-implement it with a more permissive licensing scheme. If Meteor is as good as it looks, then this should happen relatively quickly. [1] http://www.mozilla.org/MPL/1.1/ http://www.mozilla.org/MPL/1.1/