6 ms·

Is GPL really viable for a web framework? The Free Software Foundation has consistently held that linking to GPL code (not LGPL) is derived work.

by equark 14y ago

skore 14y ago
[[citation needed]]. From what I remember, the FSF is pretty consistent in saying that deriving from GPL code is derived work. If your linking constitutes a derivation (a common example would be a database handler that you adapt to your application after you've loaded it) then it is a derivation. If you just loosely call it, it is not.
- aaronblohowiak 14y ago
  Golden, Bernard (2005), "Chapter 3. Open Source Risks", Succeeding with Open Source, Addison-Wesley, p. 44, ISBN 9780321268532 You appear to be confusing GPL with the "GPL With Linking Exception" https://en.wikipedia.org/wiki/GPL_linking_exception https://en.wikipedia.org/wiki/GPL_linking_exception
  - skore 14y ago
    It is possible for a piece of software to rely on the output of another piece of software without being derivative. Hell, that's basically how any interface in the world works. As the wikipedia article on the GPL notes, the problem is not so much the GPL, but how derivative work is not that well pinned down in copyright law itself. That it appears ambiguous in the GPL is a result of that. My rule of thumb is to approach it from the angle of "what is the software worth if you take out what is linked?" - If the software can function without the linked code, it may not be derivative, but the actual question is whether it is useful without the linked code. Whether it carries out the tasks that the user needs the software for without the linked code. To me, it's more of a social question of how much the linkee is indebted to the linked. So no, I don't think I am confusing the two. https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin...
- equark 14y ago
  Meteor packages all the JS together and minifies it. That's clearly linking.
  - skore 14y ago
    No, that's packing and minification. https://en.wikipedia.org/wiki/GNU_General_Public_License#Communicating_and_bundling_with_non-GPL_programs https://en.wikipedia.org/wiki/GNU_General_Public_License#Com...
chc 14y ago
I think Meteor actually has the opposite problem: Running a web app is not generally considered to be distribution, so as long as you aren't actually giving the source code to anybody else, the requirements of the GPL don't apply to you. (IANAL, but this is my understanding.)
- bryanh 14y ago
  This is correct, and is the exact reason the AGPL was created (http://en.wikipedia.org/wiki/Affero_General_Public_License http://en.wikipedia.org/wiki/Affero_General_Public_License): to close the "not really distributed" loophole in GPL.
- ewang1 14y ago
  Wouldn't this only apply to the server side code of the app? If any proprietary code is also bundled and distributed client side by Meteor then I think the GPL provisions would apply.
- kragen 14y ago
  Meteor runs on the client, not the server. If the server sends the code to the client so that the client can run it, the code is being distributed to the client. Better make sure that you have a link to the un-minified version of your site's JS if you minify it and use Meteor, and of course don't try to restrict your users from studying, copying, modifying, and redistributing your site's JS.
- davidroetzel 14y ago
  IANAL and my understanding of the GPL in a web context is at best fuzzy, but I still believe the following to be true: The majority of application code is run on a user's browser. This means it is distributed (or conveyed) to the user. Thus, you have to offer every user of the app a possibility to obtain the unobfuscated source code. But there is more: The GPL requires you to offer not only some JS files, but everything needed to run the application. This would include everything on the server-side as well. Sencha's take on this might also be interesting in this context: http://www.sencha.com/legal/open-source-faq/ http://www.sencha.com/legal/open-source-faq/ They have been using a GPL dual-licensing model for their products for quite some time now and I suspect they consulted more than one lawyer.
ig1 14y ago
Ditto. The whole point of the LGPL is to allow linking code not to be GPL'd. It pretty much kills the usefulness of this project.
- kragen 14y ago
  It kills its usefulness for proprietary software, unless you're willing to pay the Meteor guys whatever they ask for a license. But I'd like to point out that there's actually a lot of software out there that isn't proprietary, and Meteor looks like a dramatically better way to write it.
  - ig1 14y ago
    Let's assume you have Meteor on your website: Want to use google analytics ? - nope you can't. Want to offer third-party oauth login ? - nope you can't. Want to use like/tweet/+1 buttons ? - nope you can't. GPL essentially means your website can't have anything on the client-side which is not GPL compatible. And from reading the Meteor guys website that's not what they intend, their choice of GPL was to ensure and changes to Meteor get contributed back and for that LGPL is a much better licence. Meteor's own website violates the GPL licence of Meteor as it stands (assuming it contains code from any third-party contributor).
    - deleted 14y ago
      [deleted]
    - kragen 14y ago
      It's not quite that black-and-white. Why do you think OAuth is prevented, for example? You don't have to include JS code from Twitter in your page to enable OAuth logins to Twitter. Similarly, Facebook Like buttons run in a separate iframe; you can make a clear argument that they are a separate program from your site. You're probably right about Google Analytics. It may be true that they adopted the GPL without carefully thinking it over, or it could be a deliberate choice, as with GhostScript — whose commercial customers are mostly printer companies, who are willing to pay for a license so they don't have to send their printer firmware source code to all their buyers, which the GPL would require. Sencha is another JS toolkit using the GPL to encourage people to buy licenses for proprietary use.
cfontes 14y ago
This is a major point... If I use it in my project and after a while I want to charge for the service and I don't distribute all my code, am I in trouble? if yes, I forecast a slow and steady walk into the event horizon for this nice little thing.
- sciurus 14y ago
  It doesn't matter if you charge for the service or not. As soon as you allow someone to access your project, you have to make the source code available to them.
rads 14y ago
"If the GPL doesn't work for your project, get in touch (contact@meteor.com) and we will write you a commercial license to your specifications. We are happy to be flexible. What's important is that we have a conversation about how you are using Meteor, and what support and further development you need, so we can keep everyone in the community on the same page." http://meteor.com/faq/how-is-meteor-licensed http://meteor.com/faq/how-is-meteor-licensed
davidroetzel 14y ago
tl;dr I do not think that the GPL is suitable to build an open source community around a web framework. With the current licensing it looks a lot like they are pondering a dual-licensing business: Offer a GPLed version for free and charge for commercial licenses. Since the product seems to be very promising and since the GPL is not suited for many use-cases (web startups, freelance work for clients and even many inhouse developments), this might actually work. Being a developer myself, I see nothing wrong with a bunch of other developers wanting to be paid for their work. If this is really how they want to play it, I wish them all the best. (If this really is the case, I find the current copy on their website a bit misleading, though). On the other hand, if their goal is to establish a vibrant open source community around meteor, then I think they are on the wrong track. To accomplish that you need to have a low barrier of entry for a) users of your product and b) contributors to your project. The GPL, in the case of a web-framework that blurs the client-server divide, sets the bar quite high for both groups: a) Other commenters seem to agree with me that every app developed with a GPL'ed meteor has to be put under GPL as well. The implications alone might drive some people away from using meteor, but even having to think about those things upfront can be discouraging. Some people do not like the GPL, some may not be able to work with it and some may simply want to be able to choose the license for their work themselves. b) If they are offering a commercial license, it will not be easy for them to accept outside code contributions. They need to establish some legal documents (Contributor Agreements, maybe Copyright Assignments) and a process for accepting contributions. This makes it a lot harder to contribute than simply sending a pull request. They cite the MySQL business model as something they closely studied. MySQL has a particulary bad reputation for not accepting outside contributions. And this is mainly due to their dual-licensing model. I strongly believe that Ruby on Rails became popular so quickly and still has an active community because of its liberal license (MIT). Personally I am very excited about meteor and I wish that they reconsider using another license. It does not have to be MIT, even though that is what I would choose, but even LGPL would be better IMHO.
- drudru11 14y ago
  Totally agree. I don't mind contributing to their project, but i don't think every developer, client, entrepreneur wants to open source their code.
Lazare 14y ago
It depends what the Meteor team has in mind. If they want this to be the next Django/Rails/Express/whatever, where a large and enthusiastic community both uses and develops the product then the answer is fairly clear: No, this is not a suitable license. If their idea is that it's an nominally open source project where all control and most development takes place inside the originating company, and the community mostly just pays license fees then: Sure, it's a great license. Longer clarification: Django is licensed under BSD, Rails and Express under MIT. Why? Because these licenses allow me to use these frameworks for my own webapps, without making the entire client/server code base available. I can toss together a Rails-based contacts manager, or a Django-based todo list app, and let people sign up, and even charge a monthly fee, and NOT have to give the code to the entire app out. Someone else linked to Sencha's discussion of the GPL and JS webapps, and it's highly relevant: http://www.sencha.com/legal/open-source-faq/ http://www.sencha.com/legal/open-source-faq/ In short, as long as Meteor is under the GPL, I can use the framework for free, but I cannot let anyone use a webapp I create with it without giving away all the source code. Which means that I'm very unlikely to actually install and try Meteor on my next project. My choices are basically "ignore Meteor" and "pay a license fee to the devs". Meteor is awesome, and probably well worth the license fee (whatever it might be), but it's fairly obvious that this is a huge limitation on the frameworks potential for adoption. (It's worth noting that both Django and Rails were actually developed for a project, and then released under permissive licenses, because the framework wasn't the product, and the dev teams didn't need to try and monetize it. Meteor is the product, and the dev team does need to monetize it. And, again, Meteor looks awesome! So I can fully understand why they chose GPL, and I fully support that choice! But it is worth noting the consequences of that.)
- kragen 14y ago
  In the twenty-five or so years of the free-software movement, we've built the Internet and the World-Wide Web; made the Encyclopedia Britannica obsolete by producing something dramatically better; built history's most portable operating system, which now runs everything from most smartphones to most supercomputers, with contributions from hundreds of companies, including its biggest competitors, IBM and Microsoft. But even after twenty-five years, there are still people who think they have to make a code base proprietary to make money on it. I'm horrified. What do you think will happen if you toss together a contacts manager or to-do list app and charge a monthly fee, and give out all the code, just as the Meteor devs have given out all their code to you? Maybe some of your users will decide to run the app on their own server and stop paying you. Or try to compete with you. But probably most of them will want to use the site operated by the app's primary developer. And all of your would-be competitors are just free R&D increasing the value of your site. What's so terrible about making web apps that are free software?
dangoor 14y ago
In their FAQ, they mention wanting to keep the changes people make open for now, which is why they chose the GPL. If that's the case and they're not pursuing a dual license business strategy, I'd suggest that the Mozilla Public License 2.0 is a better choice. It's very explicit that the files that come in the distribution are the ones for which derivative works need to be under the same license. If dual license is what they really want, I'm not particularly interested at this stage.
- sciurus 14y ago
  MPL 2.0 does look like a good fit. "The MPL has been approved as both a free software license (albeit one with a weak copyleft) by the Free Software Foundation and an open-source software license by the Open Source Initiative. The MPL allows covered source code to be mixed with other files under a different, even proprietary license. However, code files licensed under the MPL must remain under the MPL and freely available in source form. This makes the MPL a compromise between the MIT or BSD licenses, which permit all derived works to be relicensed as proprietary, and the GPL, which requires the whole of a derived work, even new components, to remain under the GPL. By allowing proprietary modules in derived projects while requiring core files to remain open source, the MPL is designed to motivate both businesses and the open-source community to help develop core software." - http://en.wikipedia.org/wiki/Mozilla_Public_License http://en.wikipedia.org/wiki/Mozilla_Public_License
zzzmarcus 14y ago
The problem with licensing Meteor as GPL is that it creates a high level of uncertainty. If I'm going to start a new hobby or side project, perhaps hoping that it'll get bigger someday, I still have no idea if, when or how it'll make money so it doesn't makes sense to contact Meteor to find out how much licensing is, but the doubt will always be there and as likely as not I'd just not use Meteor to avoid finding out too late that the commercial license terms are unacceptable for whatever I end up with. There's also uncertainty about what exactly I can or can't do with a GPL licensed web framework. To some it's very clear that I'll only have to release my changes to the framework, to others it's very clear that I'd have to release the whole app as GPL. To me it's unclear either way and as long as that uncertainty exists it makes using it tough call. If it's hard to justify doing a hobby project with those concerns, it'll be next to impossible to get buy-in on a new project at work. In fact, as cool as Meteor looks, and as much as I'd love to use it, I wouldn't even present it as an option. I'd prefer pay for support or hosting or add-ons or whatever; as long as I know up-front what the costs are likely to be. I don't think a more liberal license will prevent the community from contributing back, Rails, Django, Node etc. being the obvious examples. I'd love to see Meteor take off and the devs obviously deserve to make money on it, but personally the GPL just feels like it's only huge downside to an otherwise very exciting project.
pbreit 14y ago
This isn't just a web framework where all the code is on the server, Meteor code is always distributed (to the browser) so I wonder if GPL is a complete non-starter. It doesn't matter if you want to charge or not, all of your modifications on the server side would seemingly need to be distributed back out.

Is GPL really viable for a web framework? The Free Software Foundation has consistently held that linking to GPL code (not LGPL) is derived work.

by equark 14y ago

Is GPL really viable for a web framework? The Free Software Foundation has consistently held that linking to GPL code (not LGPL) is derived work.

skore 14y ago

[[citation needed]]. From what I remember, the FSF is pretty consistent in saying that deriving from GPL code is derived work. If your linking constitutes a derivation (a common example would be a database handler that you adapt to your application after you've loaded it) then it is a derivation. If you just loosely call it, it is not.

aaronblohowiak 14y ago
Golden, Bernard (2005), "Chapter 3. Open Source Risks", Succeeding with Open Source, Addison-Wesley, p. 44, ISBN 9780321268532 You appear to be confusing GPL with the "GPL With Linking Exception" https://en.wikipedia.org/wiki/GPL_linking_exception https://en.wikipedia.org/wiki/GPL_linking_exception
- skore 14y ago
  It is possible for a piece of software to rely on the output of another piece of software without being derivative. Hell, that's basically how any interface in the world works. As the wikipedia article on the GPL notes, the problem is not so much the GPL, but how derivative work is not that well pinned down in copyright law itself. That it appears ambiguous in the GPL is a result of that. My rule of thumb is to approach it from the angle of "what is the software worth if you take out what is linked?" - If the software can function without the linked code, it may not be derivative, but the actual question is whether it is useful without the linked code. Whether it carries out the tasks that the user needs the software for without the linked code. To me, it's more of a social question of how much the linkee is indebted to the linked. So no, I don't think I am confusing the two. https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin...
equark 14y ago
Meteor packages all the JS together and minifies it. That's clearly linking.
- skore 14y ago
  No, that's packing and minification. https://en.wikipedia.org/wiki/GNU_General_Public_License#Communicating_and_bundling_with_non-GPL_programs https://en.wikipedia.org/wiki/GNU_General_Public_License#Com...

chc 14y ago

I think Meteor actually has the opposite problem: Running a web app is not generally considered to be distribution, so as long as you aren't actually giving the source code to anybody else, the requirements of the GPL don't apply to you. (IANAL, but this is my understanding.)

bryanh 14y ago
This is correct, and is the exact reason the AGPL was created (http://en.wikipedia.org/wiki/Affero_General_Public_License http://en.wikipedia.org/wiki/Affero_General_Public_License): to close the "not really distributed" loophole in GPL.
ewang1 14y ago
Wouldn't this only apply to the server side code of the app? If any proprietary code is also bundled and distributed client side by Meteor then I think the GPL provisions would apply.
kragen 14y ago
Meteor runs on the client, not the server. If the server sends the code to the client so that the client can run it, the code is being distributed to the client. Better make sure that you have a link to the un-minified version of your site's JS if you minify it and use Meteor, and of course don't try to restrict your users from studying, copying, modifying, and redistributing your site's JS.
davidroetzel 14y ago
IANAL and my understanding of the GPL in a web context is at best fuzzy, but I still believe the following to be true: The majority of application code is run on a user's browser. This means it is distributed (or conveyed) to the user. Thus, you have to offer every user of the app a possibility to obtain the unobfuscated source code. But there is more: The GPL requires you to offer not only some JS files, but everything needed to run the application. This would include everything on the server-side as well. Sencha's take on this might also be interesting in this context: http://www.sencha.com/legal/open-source-faq/ http://www.sencha.com/legal/open-source-faq/ They have been using a GPL dual-licensing model for their products for quite some time now and I suspect they consulted more than one lawyer.

ig1 14y ago

Ditto. The whole point of the LGPL is to allow linking code not to be GPL'd. It pretty much kills the usefulness of this project.

kragen 14y ago
It kills its usefulness for proprietary software, unless you're willing to pay the Meteor guys whatever they ask for a license. But I'd like to point out that there's actually a lot of software out there that isn't proprietary, and Meteor looks like a dramatically better way to write it.
- ig1 14y ago
  Let's assume you have Meteor on your website: Want to use google analytics ? - nope you can't. Want to offer third-party oauth login ? - nope you can't. Want to use like/tweet/+1 buttons ? - nope you can't. GPL essentially means your website can't have anything on the client-side which is not GPL compatible. And from reading the Meteor guys website that's not what they intend, their choice of GPL was to ensure and changes to Meteor get contributed back and for that LGPL is a much better licence. Meteor's own website violates the GPL licence of Meteor as it stands (assuming it contains code from any third-party contributor).
  - deleted 14y ago
    [deleted]
  - kragen 14y ago
    It's not quite that black-and-white. Why do you think OAuth is prevented, for example? You don't have to include JS code from Twitter in your page to enable OAuth logins to Twitter. Similarly, Facebook Like buttons run in a separate iframe; you can make a clear argument that they are a separate program from your site. You're probably right about Google Analytics. It may be true that they adopted the GPL without carefully thinking it over, or it could be a deliberate choice, as with GhostScript — whose commercial customers are mostly printer companies, who are willing to pay for a license so they don't have to send their printer firmware source code to all their buyers, which the GPL would require. Sencha is another JS toolkit using the GPL to encourage people to buy licenses for proprietary use.

cfontes 14y ago

This is a major point... If I use it in my project and after a while I want to charge for the service and I don't distribute all my code, am I in trouble? if yes, I forecast a slow and steady walk into the event horizon for this nice little thing.

sciurus 14y ago
It doesn't matter if you charge for the service or not. As soon as you allow someone to access your project, you have to make the source code available to them.

rads 14y ago

"If the GPL doesn't work for your project, get in touch (contact@meteor.com) and we will write you a commercial license to your specifications. We are happy to be flexible. What's important is that we have a conversation about how you are using Meteor, and what support and further development you need, so we can keep everyone in the community on the same page." http://meteor.com/faq/how-is-meteor-licensed http://meteor.com/faq/how-is-meteor-licensed

davidroetzel 14y ago

tl;dr I do not think that the GPL is suitable to build an open source community around a web framework. With the current licensing it looks a lot like they are pondering a dual-licensing business: Offer a GPLed version for free and charge for commercial licenses. Since the product seems to be very promising and since the GPL is not suited for many use-cases (web startups, freelance work for clients and even many inhouse developments), this might actually work. Being a developer myself, I see nothing wrong with a bunch of other developers wanting to be paid for their work. If this is really how they want to play it, I wish them all the best. (If this really is the case, I find the current copy on their website a bit misleading, though). On the other hand, if their goal is to establish a vibrant open source community around meteor, then I think they are on the wrong track. To accomplish that you need to have a low barrier of entry for a) users of your product and b) contributors to your project. The GPL, in the case of a web-framework that blurs the client-server divide, sets the bar quite high for both groups: a) Other commenters seem to agree with me that every app developed with a GPL'ed meteor has to be put under GPL as well. The implications alone might drive some people away from using meteor, but even having to think about those things upfront can be discouraging. Some people do not like the GPL, some may not be able to work with it and some may simply want to be able to choose the license for their work themselves. b) If they are offering a commercial license, it will not be easy for them to accept outside code contributions. They need to establish some legal documents (Contributor Agreements, maybe Copyright Assignments) and a process for accepting contributions. This makes it a lot harder to contribute than simply sending a pull request. They cite the MySQL business model as something they closely studied. MySQL has a particulary bad reputation for not accepting outside contributions. And this is mainly due to their dual-licensing model. I strongly believe that Ruby on Rails became popular so quickly and still has an active community because of its liberal license (MIT). Personally I am very excited about meteor and I wish that they reconsider using another license. It does not have to be MIT, even though that is what I would choose, but even LGPL would be better IMHO.

drudru11 14y ago
Totally agree. I don't mind contributing to their project, but i don't think every developer, client, entrepreneur wants to open source their code.

Lazare 14y ago

It depends what the Meteor team has in mind. If they want this to be the next Django/Rails/Express/whatever, where a large and enthusiastic community both uses and develops the product then the answer is fairly clear: No, this is not a suitable license. If their idea is that it's an nominally open source project where all control and most development takes place inside the originating company, and the community mostly just pays license fees then: Sure, it's a great license. Longer clarification: Django is licensed under BSD, Rails and Express under MIT. Why? Because these licenses allow me to use these frameworks for my own webapps, without making the entire client/server code base available. I can toss together a Rails-based contacts manager, or a Django-based todo list app, and let people sign up, and even charge a monthly fee, and NOT have to give the code to the entire app out. Someone else linked to Sencha's discussion of the GPL and JS webapps, and it's highly relevant: http://www.sencha.com/legal/open-source-faq/ http://www.sencha.com/legal/open-source-faq/ In short, as long as Meteor is under the GPL, I can use the framework for free, but I cannot let anyone use a webapp I create with it without giving away all the source code. Which means that I'm very unlikely to actually install and try Meteor on my next project. My choices are basically "ignore Meteor" and "pay a license fee to the devs". Meteor is awesome, and probably well worth the license fee (whatever it might be), but it's fairly obvious that this is a huge limitation on the frameworks potential for adoption. (It's worth noting that both Django and Rails were actually developed for a project, and then released under permissive licenses, because the framework wasn't the product, and the dev teams didn't need to try and monetize it. Meteor is the product, and the dev team does need to monetize it. And, again, Meteor looks awesome! So I can fully understand why they chose GPL, and I fully support that choice! But it is worth noting the consequences of that.)

kragen 14y ago
In the twenty-five or so years of the free-software movement, we've built the Internet and the World-Wide Web; made the Encyclopedia Britannica obsolete by producing something dramatically better; built history's most portable operating system, which now runs everything from most smartphones to most supercomputers, with contributions from hundreds of companies, including its biggest competitors, IBM and Microsoft. But even after twenty-five years, there are still people who think they have to make a code base proprietary to make money on it. I'm horrified. What do you think will happen if you toss together a contacts manager or to-do list app and charge a monthly fee, and give out all the code, just as the Meteor devs have given out all their code to you? Maybe some of your users will decide to run the app on their own server and stop paying you. Or try to compete with you. But probably most of them will want to use the site operated by the app's primary developer. And all of your would-be competitors are just free R&D increasing the value of your site. What's so terrible about making web apps that are free software?

dangoor 14y ago

In their FAQ, they mention wanting to keep the changes people make open for now, which is why they chose the GPL. If that's the case and they're not pursuing a dual license business strategy, I'd suggest that the Mozilla Public License 2.0 is a better choice. It's very explicit that the files that come in the distribution are the ones for which derivative works need to be under the same license. If dual license is what they really want, I'm not particularly interested at this stage.

sciurus 14y ago
MPL 2.0 does look like a good fit. "The MPL has been approved as both a free software license (albeit one with a weak copyleft) by the Free Software Foundation and an open-source software license by the Open Source Initiative. The MPL allows covered source code to be mixed with other files under a different, even proprietary license. However, code files licensed under the MPL must remain under the MPL and freely available in source form. This makes the MPL a compromise between the MIT or BSD licenses, which permit all derived works to be relicensed as proprietary, and the GPL, which requires the whole of a derived work, even new components, to remain under the GPL. By allowing proprietary modules in derived projects while requiring core files to remain open source, the MPL is designed to motivate both businesses and the open-source community to help develop core software." - http://en.wikipedia.org/wiki/Mozilla_Public_License http://en.wikipedia.org/wiki/Mozilla_Public_License

zzzmarcus 14y ago

The problem with licensing Meteor as GPL is that it creates a high level of uncertainty. If I'm going to start a new hobby or side project, perhaps hoping that it'll get bigger someday, I still have no idea if, when or how it'll make money so it doesn't makes sense to contact Meteor to find out how much licensing is, but the doubt will always be there and as likely as not I'd just not use Meteor to avoid finding out too late that the commercial license terms are unacceptable for whatever I end up with. There's also uncertainty about what exactly I can or can't do with a GPL licensed web framework. To some it's very clear that I'll only have to release my changes to the framework, to others it's very clear that I'd have to release the whole app as GPL. To me it's unclear either way and as long as that uncertainty exists it makes using it tough call. If it's hard to justify doing a hobby project with those concerns, it'll be next to impossible to get buy-in on a new project at work. In fact, as cool as Meteor looks, and as much as I'd love to use it, I wouldn't even present it as an option. I'd prefer pay for support or hosting or add-ons or whatever; as long as I know up-front what the costs are likely to be. I don't think a more liberal license will prevent the community from contributing back, Rails, Django, Node etc. being the obvious examples. I'd love to see Meteor take off and the devs obviously deserve to make money on it, but personally the GPL just feels like it's only huge downside to an otherwise very exciting project.

pbreit 14y ago

This isn't just a web framework where all the code is on the server, Meteor code is always distributed (to the browser) so I wonder if GPL is a complete non-starter. It doesn't matter if you want to charge or not, all of your modifications on the server side would seemingly need to be distributed back out.