31–40 of 121 posts
Sencha took a similar approach with ExtJS and it pains me to watch it falling into obscurity. The framework itself is elegant and well thought-out; it seems that everything Backbone and its various offshoots give us now was already available there years ago.
Personally, I'd prefer they just kept it closed source and charged money for it rather than making it "open source, but not really since you can't use it to build anything unless you give out all your code or can lawyer your way past this obnoxious, ambiguously worded license". I don't care about being able to look at somebody else's source code. I just want something that I can use. Meteor looked really cool until I…
Earlier quoted context omitted.
> linking against a separately distributed GPL library. Unless you are changing your underlying JavaScript implementation, I don't think you are really linking your code to anything in this case. It could be that your JavaScript runtime got linked to the library, but the runtime/interpreter being GPL doesn't require your programs to be GPL too.
I meant linking in the web sense - literally pointing at some offsite bit of code that you do not distribute and adding its APIs to the context you're currently running in.
The real reason permissive licences are preferred is developers are greedy. I know, I'm a developer and I'm greedy. I don't want to admit I'm using other people's code to do my work. I want to silently include that code and pretend that I did all of it myself and impress people with my amazing programming skills. If I have to buy a license I have fess up, and admit to myself I need their code, whereas if I can just u…
But then practically all my own current work is open-sourced which probably skews my opinions.
The real reason permissive licences are preferred is developers are greedy. I know, I'm a developer and I'm greedy. I don't want to admit I'm using other people's code to do my work. I want to silently include that code and pretend that I did all of it myself and impress people with my amazing programming skills. If I have to buy a license I have fess up, and admit to myself I need their code, whereas if I can just u…
And I don't think its greed. Not many applications on any platform gets written completely from scratch without using other libraries.
GPL doesn't require you to distribute your server-side code if you are hosting it on your own servers (AGPL does). The client side code does have to be open sourced since it is distributed but Javascript code is pretty worthless without the server-side API, HTML and CSS that goes with it. In other words, all the commercial license does from a business point of view is allow you to sue people who copy your client side…
Well now, that depends heavily on what you're doing with the JavaScript. Our JS, for example, is far from worthless and we already have problems with people ripping us off.
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.
I think I prefer the paid-support model a-la RedHat. I think the OP makes a good point of this licensing possibly hindering uptake/contributions to the Meteor project. Just by virtue of Meteor choosing this licensing model, I've lost some of my excitement to try it out. I would most certainly use it for something commercial and because it looks so sweet I would be willing to shell out some $ for, say, some email supp…
What if sending them an email that took as long to write as this HN post would get you a quote?
Psychology of product purchasers is fascinating.
Personally, I'd prefer they just kept it closed source and charged money for it rather than making it "open source, but not really since you can't use it to build anything unless you give out all your code or can lawyer your way past this obnoxious, ambiguously worded license". I don't care about being able to look at somebody else's source code. I just want something that I can use. Meteor looked really cool until I…