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 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.
You're thinking of adopting a framework that has been publicly released for a grand total of three days and this is the source of risk to your business plan?
Have you tried talking to the Meteor folks directly about licensing terms, yet?
Maybe so. This comment sounds like the opening of a public negotiation, an aggressive one in which we try to get the other side to name a number first. We do so in public to leverage additional social pressure ("Look at all the commenters who want you to sell your work at a fixed rate, so that we can derive much more valuable things from that work and keep the profits for ourselves") and to better evoke the as-yet-imaginary competitors ("you should give out your code on flat-rate terms, because otherwise we'll switch to Project X, which is just like Meteor, has a more permissive licensing scheme, and ships with ponies and rainbows").
The last threat is pretty empty, though. When a customer tells you "I don't like your price, I'm going to wait six months and download a clone of your code for free from the Internet" the correct response is generally "good luck with that, and enjoy your six-month vacation". Those clones will always exist - in the case of Meteor, unless it proves to be a flash in the pan, they will exist by the dozen, and some of them may even get written by programmers with the same skill as the Meteor folks, and I wouldn't even rule out the ponies and/or rainbows. But that doesn't mean Meteor stands no chance against these "free" alternatives: No code is one hundred percent free. You pay for the code, you pay for the support, you pay a developer to do the support, or you pay with time, but you still have to pay.
And the first threat is empty, too, because Meteor doesn't need to court everyone in the world as a customer. It doesn't necessarily matter even if their non-GPL price is too high for all but one customer. They may only need one customer. Ask the folks who sold MySQL to Oracle.
No, Meteor isn't a risk to my business plan, because I wouldn't put a three-day-old framework into my business plan under any circumstances. What I am saying is that I won't ever put a framework which has this license plus an obfuscated pricing model into my business plan, and that makes me sad.
And no, I haven't talked to the Meteor folks. I have no doubt that they're completely lovely people, but really, there's nothing to talk about yet. As explained above. There wouldn't be anything to talk about until after a fairly substantial amount of code had been written. As explained above. And that code won't be written with Meteor, for reasons explained above. If they want to give assurances about the nature of their licensing terms, then there's no reason they can't do so in public.
And yes, I know that many products are sold on a negotiated, non-fixed-price basis. I generally do everything possible to avoid buying those products, as that is too often a cover for predatory pricing practices. There are plenty of ways to do sensible price differentiation while still stating your policies clearly.
The folks who sold MySQL, sold MySQL to Sun before Sun was bought by Oracle. They were able to sell to Sun because they had a LOT more than one customer using MySQL in the first place.
It's a commercial product that also happens to be available under a free license you can't use. How does the second part impact the first?
Edit: it seems the implicit context in your post is that you would use this if it were free under a permissive license, but not if it costs money or is GPL. That's not an uncommon position, but it's not something that rises to a multi-paragraph complaint on HN. You're complaining about the "GPL" instead of complaining that "the authors want to charge money", and that seems inequitable and unfair. If they were just another tool vendor, you wouldn't have posted: basically you're punishing them for releasing free software.
With meteor there is no knowing how the pricing will be without asking first; but nkoren's concern is that they won't know a viable business model until after significant work has gone into development. At that point if nkoren doesn't like the pricing they would have to switch to another framework.
I never got the impression that nkoren was against paying for meteor, just against taking a leap of faith on _any_ system which would require significant investment of time before finding out even a general idea of how the pricing works.
So I guess I'm saying that I understand that argument, but I don't buy it. Which side of the argument you land on tends to be colored mostly by your emotional feelings about the GPL (I find as I age that I'm becoming more and more a pinko commie copyleft fanboi, for example), and not really well grounded in practice.
After enough years and enough projects, I find my perspective is broader. The GPL helps more than it hurts. Efforts to explicitly avoid the GPL (not just to use permissive licenses for free software projects -- that's clearly a good thing) tend to hurt more than they help.
Good communities are founded on mutual respect and voluntary engagement.
No, the GPL says "If you use my code, you have to let people use yours too"
"If you use my code, you have to share yours under the terms I determine."
It muddies my main point about the relative value of the code in question, however.
I agree (almost) completely. When the pricing is obfuscated you can't take the risk of building software without knowing how much the license is going to cost you. Where I don't agree is that you can probably talk about pricing before you start coding, while developing your business plan. Hopefully they are flexible enough to have reasonable negotiations even though your business plan is not yet fixed in stone. Ideally the negotiations would simply be them stating a fixed price and a bit of haggling. It's complicated if they want a percentage of profits. But you don't know until you ask.
And your response to this is to whine about it and tell us how they're limiting their user base.
The MPL requires that anything derived from their library has to remain open-source. That's great. Totally support it. The GPL, as I understand it, requires that anything used with their library must be open-source. That's a problem.
With this in mind, the MPL does sound like the better choice. It's still vastly superior to BSD or MIT, since it requires you and me to release any changes we made to the library itself.
What I think this means is that the GPL (or a new successor to it, since Richard Stallman is too much of a curmudgeon) needs to start distinguishing between portions of web applications according to their origin, to enable the various scenarios that are possible when distributing executable code but currently not webapp client-side code.
GPL let you keep things in house if you don't distribute. Google does that all the time. A lot of their stuff isn't contributed back.
And heck, it's a BAD thing, but they CAN do it.
Yeah more permission just let companies make more money off free stuff; its only in some rare occasions that they truly contribute back, unless it's GPL and they're forced to use it because they distribute it (although many just go the illegal way)
Now if you don't want GPL and no alternative that is free exists, well you know, code it yourself? Or are the people coding for free supposed to pay your lunch too?
Unless they change their licensing terms, when Yahoo's Mojito framework finally comes out (or some other competitor who is just as good as Meteor) under MIT license, Meteor will go the way of ExtJS, Powerbuilder, HD-DVD and Betamax.
On github: https://github.com/yahoo/mojito/
Edit: It's released under a BSD license.
Also, have you talked to them? Like, actually written an email? Maybe it's not so bad.
If you haven't even figured out your revenue stream you probably are prematurely optimizing choice of license. Besides, you could still make use of it for prototyping and figuring out better your product requirements.