I think you're turning this too corporate too soon.
At this stage your most powerful evangelists will be hobbyists and spare-timers. When I write code, I like to write it open-source. Setting the obviously negative connotation aside, it is objectively true that the GPL code, compiled or no, is a license virus that spreads so fundamentally that linking with non-GPL-compatible code violates the terms. Because the distinction between client and server code is blurred, this makes the territory murky and introduces overhead into the developer's mind as to whether what is being written can ever be open-sourced or not.
---
Besides dampening enthusiasm for using Meteor, this can also reduce the quality and usefulness of modules being released. This sounds counter-intuitive, but consider the following hypotheticals:
Company A develops and maintains a production-ready module that is especially useful for anyone using Meteor. However, the legal department says that the company cannot release software under GPLv3 (this is common). Company B and Person Z want to use it, the former with a commercial license, the latter with a open-source license.
Because Company A cannot release the module under a permissive license, they can 1) Release it permissively but in a GPL-incompatible license, thus banning all Person Z's from developing open-source software with it legally, 2) Opt not to release it at all to Person Z, and just license it to Company B. 3) Abandon Meteor for something they can both release openly (to give back and get more eyes and hands) and develop in-house.
Company C uses a closed-source library, because they're required to use it because it's the only one out there, and they're contractually obligated because that's the business they're in. They use Meteor to get the project off the ground and they never move off, because it's what they know and are good at. Company C can never write, for example, a white-label platform to distribute to Company X and Company Y, because at best they could only distribute the platform sans non-GPL parts. And while the licensing is viral, the understanding of it will not be. So it may lead to GPL violations down the road because Company X didn't understand, and Company C may be holding the bag. Legal doesn't want the company to take the risk and assume liability, so it says "no" and kills the project's use of Meteor.
Company D thinks about the hypothetical case of Company C, only it was just founded and is looking at Meteor. Maybe it was founded by Person Z. Because of the hypothetical of Company C, and because Company D doesn't know what their business is yet, they decide to avoid a potential future nightmare and write their own framework. Maybe they open-source it, because it's compelling and useful, and they want to get as many eyeballs and hands on it as they can, improving it.
---
tl;dr I was super-excited about Meteor, but now that it's GPL I will not be touching it with a ten foot pole. I am really sad about this.
Because I value developer freedom, I do not use GPL'd code in my projects, even if it is objectively good. Because I support open-source, and want to give back when I can I do not want use Meteor with a commercial license. So because of your choice of license - and for no other reason - I can not and will not use Meteor.
> I think you're turning this too corporate too soon.
That may or may not be, only time will tell. The important thing is to be up front about it, though. There are advantages and disadvantages to companies in something like this: often they can move faster than someone working part time, and they're probably going to be friendlier to those who need support for their own commercial endeavors (anyone remember the famous "fuck you" slide from DHH?).
There are certainly downsides too (I'm not really interested in GPL code if I can help it), but it's theirs to decide. The only thing I want is for them to be up front about what's what.
Obviously you want to release only code that will help you code less in the future (ie: let others maintain feature X for FREE for us; but don't give them what MATTERS)
And that's the main concern with all the anti-GPL folks - that's also the very reason why the GPL exists.
Having developed and released something under the GPL a long time ago, I am not anti-GPL, but that doesn't mean I'm not wary of it.
> Obviously you want to release only code that will help you code less in the future
No, I want to release code other people might find useful.
> ie: let others maintain feature X for FREE for us
This sounds naive. Virtually nobody writes a library then abandons it when other people start helping out.
> don't give them what MATTERS
"What matters" is highly subjective and different to different people. What matters to Twitter is the userbase and user experience. So they open-source their database stuff, Bootstrap, and a plethora of other things. And why not?
It's not hypocritical. The GPL was critical to the fight against closed OSes and the closed tools that made writing software essentially limited and pay-to-program.
My view of open-source and programming in general is that there are many things that programming can help you do. More often than not, these are the same things. The more programmers can help each other to spend more time writing things that are great, the better off we all are.
The GPL fights proprietary software, but for things that are not products on their own, but are designed to be a component of or integrated into other products, it can also fight other programmers as well. I use GPL software, but I don't use GPL libraries or frameworks. (The LGPL is less selfish - the whole software ecosystem doesn't need to open for it to play its part, but the library damn well stay open.)
At this stage your most powerful evangelists will be hobbyists and spare-timers. When I write code, I like to write it open-source. Setting the obviously negative connotation aside, it is objectively true that the GPL code, compiled or no, is a license virus that spreads so fundamentally that linking with non-GPL-compatible code violates the terms. Because the distinction between client and server code is blurred, this makes the territory murky and introduces overhead into the developer's mind as to whether what is being written can ever be open-sourced or not.
---
Besides dampening enthusiasm for using Meteor, this can also reduce the quality and usefulness of modules being released. This sounds counter-intuitive, but consider the following hypotheticals:
Company A develops and maintains a production-ready module that is especially useful for anyone using Meteor. However, the legal department says that the company cannot release software under GPLv3 (this is common). Company B and Person Z want to use it, the former with a commercial license, the latter with a open-source license.
Because Company A cannot release the module under a permissive license, they can 1) Release it permissively but in a GPL-incompatible license, thus banning all Person Z's from developing open-source software with it legally, 2) Opt not to release it at all to Person Z, and just license it to Company B. 3) Abandon Meteor for something they can both release openly (to give back and get more eyes and hands) and develop in-house.
Company C uses a closed-source library, because they're required to use it because it's the only one out there, and they're contractually obligated because that's the business they're in. They use Meteor to get the project off the ground and they never move off, because it's what they know and are good at. Company C can never write, for example, a white-label platform to distribute to Company X and Company Y, because at best they could only distribute the platform sans non-GPL parts. And while the licensing is viral, the understanding of it will not be. So it may lead to GPL violations down the road because Company X didn't understand, and Company C may be holding the bag. Legal doesn't want the company to take the risk and assume liability, so it says "no" and kills the project's use of Meteor.
Company D thinks about the hypothetical case of Company C, only it was just founded and is looking at Meteor. Maybe it was founded by Person Z. Because of the hypothetical of Company C, and because Company D doesn't know what their business is yet, they decide to avoid a potential future nightmare and write their own framework. Maybe they open-source it, because it's compelling and useful, and they want to get as many eyeballs and hands on it as they can, improving it.
---
tl;dr I was super-excited about Meteor, but now that it's GPL I will not be touching it with a ten foot pole. I am really sad about this.
Because I value developer freedom, I do not use GPL'd code in my projects, even if it is objectively good. Because I support open-source, and want to give back when I can I do not want use Meteor with a commercial license. So because of your choice of license - and for no other reason - I can not and will not use Meteor.