We released under the GPL Tuesday because our single goal was to share our work and direction of thinking with everyone. We hoped to spur a discussion about new ways to build apps that dramatically changes the skill sets required and the time it takes. We look at Meteor as part of an exciting transition from LAMP to a new architecture of rich client applications (see also http://www.firebase.com/ that launched yesterday!).
That's still the main focus for now. Hundreds of developers have deployed apps to meteor.com. We've got pull requests for new features to sort out, and many technical questions to answer. There's a whole buffer of screencast ideas we want to do.
The four of us are a company. We intend to make money while committing ourselves to an open-source strategy. We want to see great software -- not just ours -- be something developers can sell. So while we'll give away much of what we build, we'll also look for places where developers who gain benefit from Meteor can give something back.
We did not expect such strong interest in writing closed source commercial apps this quickly on the platform. It's clearly something we have to sort out faster than we thought, and we will. For now our offer stands: please just write us if you need a commercial license for a closed source project and we will find a way to accommodate your needs. I'd imagine over the next couple weeks we'll have more concrete things to say.
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.
Lots of people will argue against the GPL on philosophical grounds alone.
I'm going to argue against it based on its ambiguity. Just reading this thread illustrates the problem clearly. In the old days of simple, standalone applications and libraries on a single machine, the obligations of the recipient of the source code was clear: your own code must also be GPL compatibile. With this new model of some of the code existing on the server and some on the client, and the GPL's use of the term "derivative work," it's very unclear to the average programmer what his or her obligations under the license are. Ultimately you as the copyright holder have to enforce your license, and the ambiguity in the meaning of the license, your motivation for choosing the license, and your intentions make things muddled.
If you are simply looking for a "copyleft" license in which people must contribute changes to Meteor back, that's fine, but the LGPL or MPL are probably better license choices.
If you want to ensure that your project is only used for open source applications with case-by-case commercial licensing exceptions, that's fine, but the AGPL is a better license choice.
Sounds good. I just want to add that sometimes it's not about "wanting to write closed source apps", sometimes it's more complicated than that. Like, the app integrating with other systems that can't be GPL'ed, or just lawyers not willing to take a chance in cases where it's not immediately obvious what's GPL compatible.
Sometimes companies who love and contribute to open source just can't use GPL'ed software, for technical reasons, for lawyer reasons, for FUD, etc.
I, for one, think it would be an awful shame for your cool tech to not achieve the adoption it deserves, just because of GPL.
I completely understand where your coming from. However, I think it's worth stressing that - from what I've seen - there are two major concerns.
1) Ambiguity. A lot of people aren't so much concerned over the license restrictions you have placed on the project, as completely confused over what those restrictions are. The GPL is written in a way which is extremely ambiguous for a JS framework and (partly) as a a result it is a vanishingly rare license in the web framework/JS space. You should spell out your understanding of what the license does and does not allow on your website.
1b) Your second option ("just send us an email") is also full of ambiguity. For good or ill, people in western cultures tend to hate this sort of haggling. A price sheet would be good, or at LEAST some clarification of the type of commercial license you imagine. Are you expecting to charge a flat rate per developer? Per website? Per visitor? Are you looking for revenue sharing deals? If I want to use Meteor for a closed-source app am I looking at the price of a cup of coffee? The price of a steak dinner? The price of a new smartphone? The price of a new car? Also, what protection do I have from you deciding to slash your commercial license costs by 80% after you think over the response you've been getting?
2) I think a lot of the concern is coming not so much from people who want to write closed source commercial apps as from people concerned that the restrictive license will hamper uptake. Everyone wants to get in on the ground floor of the next Rails/Django/Backbone, and to be able to brag in job interviews looking for an expert Meteor dev "sure, I've been using it since version 0.3!" But dual-licensed projects (like ExtJS) tend to have relatively low adoption. If nobody used Meteor, then Meteor's future isn't going to be as bright, and I'm less excited about using it myself. If everyone is using Meteor, then Meteor's future is bright, and it would behove me to learn it ASAP.
How are you planning to deal with pull requests? i.e. will you require signing CLA (like dojo does http://dojofoundation.org/about/cla )? I assume you are not going to keep commercial and GPL codebases separate, so you need some kind of permission from the contributors that you can re-license/sell their code?
I'm really glad to see you responding to this, and I'll definitely keep tabs on Meteor to see how things play out. My sense is that you'll need to alter your business model; "talk to us to discuss pricing" is only really viable if you have a very niche product or a very large sales team. I'd recommend taking a look at companies like Sencha and 10gen to see if their kind of business models would work for you.
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.
their "talk to us and we'll see what we can do" policy puts too much risk into my business plan
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.
Um... how is "talk to us and we'll see what we can do" a problem? Isn't that exactly how proprietary licensing works for non-shrink-wrap developer tools like this. You'll get the same response if you want to buy ClearCase or a CAD tool, etc...
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.
I find it hard to stomach the attitude of this comment.
You are sitting on top of a huge stack of free, enterprise-grade software which has sprung up in large part because of the insistence of some of its authors to use GPL. The authors of a little new library that sits on top of it ask that you open source the portion of your product that you derive from it. Not your whole product, not even the whole client-side part of it - a portion of the client-side javascript that you derived from their library.
And your response to this is to whine about it and tell us how they're limiting their user base.
Fully agree, AND it's just bad business decision by them. At this point, what they want is Meteor being used by as many developers as possible. That's a big reason Rails, Node.js, etc got so successful. Instead, they cut off their own feet before learning how to walk.
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.
It's under the GPL, not the AGPL. Provided that you're using it as a web platform, why would this end up being a big deal? The client has your source anyways, right, in the form of client-side JS?
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.
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 code. That's a pretty poor incentive since most businesses don't even care about people stealing their Javascript.
In addition, as mentioned in the article, the GPL license makes people feel like they are contributing because they legally have to rather than because they want to give back to the community, which is not a good thing from a psychological point of view[0].
FWIW, I would advise the Meteor team to pick a more permissive license and reconsider their business model. Perhaps they can provide consulting, hosting, job board, certification, etc.?
…but Javascript code is pretty worthless without the server-side API, HTML and CSS that goes with it.
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.
First of all, it's of course the Meteor team's prerogative to chose whatever license they want, and wanting attribution and pull requests is in no way an unworthy cause.
That said, GPL made me look twice. Mainly because client and server are so intertwined, that I assume the entire app would need to be GPL'd to use Meteor without getting a commercial license. Now I've nothing against the dual licens, and paying for a framework that makes us money , but before shopping Meteor around the company it'd be good to have some specifics on what they're thinking in terms of a commercial license model. I hope that's on their priority list. It's hard to motivate investing in something that may later turn out to be prohibitively expensive.
LGPL with a linking exception for platforms that require solid binaries (like iOS, some embedded systems) covers the vast majority of use cases that the "anything but GPL" crowd cares about.
In Meteor's case, as it's middleware, the LGPL would be the more appropriate license anyway.
I get the feeling that they're searching for business models with Meteor. The most obvious one would be optimized paid hosting ala Heroku...
They're making an amazing framework - something a lot of us have been waiting for. They spent time & energy on it, and yet make it freely available. The only thing they ask in exchange is to share what you do with it under the same terms, or pay for their work if you really want/need to be proprietary.
I'm always amazed by this reaction - ie being ok to use the generosity of others, but refusing to reciprocate.
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 realized they had those two points exactly backwards.
GPL with the dual licensed business model is fine with me, but they ought to be a bit clearer about that and state it up front. Also, is there a company the copyright is assigned to? It's not very clear at Meteor.com. Wandering around, I got this, which talks about "Meteor Development Group" ( http://www.meteor.com/contact ), but... there's no Inc or LLC or anything like that.
Also, when they talk about contributing, they don't write about having to sign a copyright assignment, which they must do if they want to continue to own the copyright to the whole thing, and thus be able to dual license it.
Furthermore, "get in touch and we'll write you a commercial license" doesn't sound like something very easy to evaluate, compared to, say, a pricing page. "Well, how much ya got, anyway?"
It is pretty early for them, though, it would appear, so maybe it's much ado about nothing, and as they work things out, they'll make things clearer and/or change the license.
It took years to convince the wider commercial technical community to so much as expose portions of their source code, regardless of license. It's invaluable for bug identification, security auditing, and general programmer education. I'm glad they're sharing it under any license, and I hope your attitude does not become more widespread.
How is dual proprietary/GPL anything other than strictly less obnoxious than proprietary alone? You can, after all, stick your fingers in your ears and pretend that it's proprietary alone, and there will be no observable difference.
You can use Meteor. I quote from FAQ: If the GPL doesn't work for your project, get in touch ([email protected]) and we will write you a commercial license to your specifications.
I met these guys last night, and I'd really recommend you write them before you let the GPL stop you from developing software using Meteor. It sounds like they'd be happy to license it otherwise to anyone that wants to use it now, but they don't want to neuter their monetization for all the people that sign up later. (If I were them, I'd formalize that fact and dual-license for early adopters to bootstrap their community.)
We started digging into Meteor this week (we are using Node.js with express/LazyBoy etc... now) and were really excited about it.
But now, this has created FUD for us.
It's all so complex and confusing at a time when we really just want to be writing code. Our startup is not far enough along to know for certain what licensing terms make sense.
I can't believe we will be alone in having this reaction. Which is a shame because Meteor had such a chance of being a real big thing.
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 support or maybe for some bleeding-edge features.
Having to worry about not being able to use Meteor in a commercial capacity without knowing the price-point breaks the deal off the bat. I'm a one man team and don't have the time nor resources to swim through legalities and pricing--I need to be writing code.
This isn't to say, though, that if I wanted to do something outside of the scope of a commercial app I wouldn't try Meteor--but who knows when/if that will happen.
That's kind of a silly view. You would rather spend 6 months "writing code" than spend 1 day negotiating a contract that would save you 6 months of effort?
What if sending them an email that took as long to write as this HN post would get you a quote?
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.
This is by no means a clear cut situation. The question of whether a piece of code which uses this library is a "derivative work" is not an easy one to answer, and the GPL only applies in situations where one is distributing said work.
Imagine if the client side libraries for Meteor end up in the Google CDN. Then you're only distributing your own code and linking against a separately distributed GPL library. Beyond that, you don't even care if the library is actually Meteor, you just care that it has the API that you use, meaning it can't really be suggested that you know you're linking against GPL code.
What about the server/client split? Could you make an argument that they're implementation agnostic to one-another? So why would you need to distribute your server side code just because you distribute your client code? Simple answer is that you don't under the GPL.
> 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.
Nokia faced a similar problem after they bought Trolltech (creator of Qt). How to increase adoption and encourage community contributions. They opted for LGPL which, as mentioned elsewhere in the comments, allows proprietary software to link to the Qt source.
That's one thing that has been bugging me since the first time I've heard of GPL. If I use a library or framework that's licensed under GPL, without modifying said library/framework in any way, do I still have to (as TFA puts it) "extend the copyleft nature" of GPL to my code? It would be great if someone could finally lay this question to rest.
I think it won't be considered derived work if you simply include the Meteor library as a separate script tag. But I don't think Meteor separates out their library code from your Meteor client side code. In addition, if you minify the concatenation of Meteor code with all your other client side js libraries, then I believe that will trigger the derived work provision.
I agree. It would be very hard for a lawyer to prove that using a public API amounts to derived work. Even so, GPL allows modified but not distributed versions (like you would see on a meteor server). The author of this blog post does not seem to fully understand GPL.
Other folks have already pointed out that using a library does not constitute a derivative work, so the author's point is irrelevant anyway.
There are times when BSD license and equivalent are sensible choices. Berkeley was releasing a reference set of source code. Their whole point was to have a common platform that everyone was building off of. Similarly, a BSD licensed reference implementation of TCP/IP back in the day meant that everyone could get the protocol up and running much faster with far fewer inconsistencies. BSD licensing is useful for social engineering.
But for most cases this isn't so. Why would anyone who wrote a JavaScript library and gave it away want to make it easy for someone else to build a company around taking their work, extending it a little, selling it, and giving nothing back other than enough tidbits to keep the community (if any) from getting up in arms? This is what happened to the Lisp machines, and it's exactly why the GPL is the way it is. Businesses have a fiduciary responsibility to maximize shareholder profits. If you're selling software, that means minimizing costs and maximizing income. It is the legal obligation of a company to take any permissively licensed code it can get its hands on and thinks will speed things up, extend it a little, and sell it. My response: if I'm not trying to engineer your behavior, stop leaching off the community and buy your underlying components.
The GPL exists for a reason. Every so often, some cheap bastard complains about it because he can't make a quick buck by ripping someone else off. Tough. That's why it's there. You want to use my work on this? Give me yours in exchange.
> Businesses have a fiduciary responsibility to maximize shareholder profits. If you're selling software, that means minimizing costs and maximizing income. It is the legal obligation of a company to take any permissively licensed code it can get its hands on and thinks will speed things up, extend it a little, and sell it.
This is not true.
First, not every business is a corporation or has shareholders.
Second, fiduciary responsibility does not require maximizing shareholder value (or profits). This has been explained several times here on HN and elsewhere by people who know much more about it than me. Here's one good explanation and discussion:
Excerpt: "...there is no law stating that the purpose of a corporation must be to maximize shareholder return. The corporation’s purpose may be any legal purpose, chosen by the creator and/or the shareholders. There is no requirement of law that profit or the maximization of value or return must be paramount or even on the list of objectives. The overwhelming majority of U.S. corporations have in their articles of incorporation an article stating that the corporation shall have the right to engage in any legal activity."
I dislike GPL because it makes business decisions (licensing concerns) get in the way of any and all programming.
Sometimes I make a lib that I want to use for myself, proprietary but not profit making. Sometimes I later want to use that library in a consulting project (now it's profit making). In general, I don't know whether all the desired end uses of my code will be commercial, open source, or just simply code I use personally but don't want to release.
(I believe the GPL triggers upon release/distribution of software, right? If I keep my modified version on my local system and don't sell it or ship it then there's no conflict. However, using it on my personal machine to serve up a publicly accessible website, I believe, also triggers it. Since lots of my "personal" code gets used on my personal, non-commercial, web site, I stay away from GPL even when I think I'm never shipping a piece of code.)
Am I missing something here? My understanding is that when you use GPL software in your product, you are not required to GPL your own code unless your code and the GPL code are compiled into the same executable that is distributed to the user. Looking at the Meteor website's front page, I don't see anything that suggests it compiles your code and its own coffee into a single executable, so I don't think that using it would require you to GPL anything except possibly any customizations that you make to Meteor itself.
Obviously this is not legal advice, and may in fact be the delusional ramblings of someone who has no understanding of the GPL. But please enlighten me if I'm wrong.
[+] [-] debergalis|14 years ago|reply
We released under the GPL Tuesday because our single goal was to share our work and direction of thinking with everyone. We hoped to spur a discussion about new ways to build apps that dramatically changes the skill sets required and the time it takes. We look at Meteor as part of an exciting transition from LAMP to a new architecture of rich client applications (see also http://www.firebase.com/ that launched yesterday!).
That's still the main focus for now. Hundreds of developers have deployed apps to meteor.com. We've got pull requests for new features to sort out, and many technical questions to answer. There's a whole buffer of screencast ideas we want to do.
The four of us are a company. We intend to make money while committing ourselves to an open-source strategy. We want to see great software -- not just ours -- be something developers can sell. So while we'll give away much of what we build, we'll also look for places where developers who gain benefit from Meteor can give something back.
We did not expect such strong interest in writing closed source commercial apps this quickly on the platform. It's clearly something we have to sort out faster than we thought, and we will. For now our offer stands: please just write us if you need a commercial license for a closed source project and we will find a way to accommodate your needs. I'd imagine over the next couple weeks we'll have more concrete things to say.
[+] [-] koko775|14 years ago|reply
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.
[+] [-] joeshaw|14 years ago|reply
I'm going to argue against it based on its ambiguity. Just reading this thread illustrates the problem clearly. In the old days of simple, standalone applications and libraries on a single machine, the obligations of the recipient of the source code was clear: your own code must also be GPL compatibile. With this new model of some of the code existing on the server and some on the client, and the GPL's use of the term "derivative work," it's very unclear to the average programmer what his or her obligations under the license are. Ultimately you as the copyright holder have to enforce your license, and the ambiguity in the meaning of the license, your motivation for choosing the license, and your intentions make things muddled.
If you are simply looking for a "copyleft" license in which people must contribute changes to Meteor back, that's fine, but the LGPL or MPL are probably better license choices.
If you want to ensure that your project is only used for open source applications with case-by-case commercial licensing exceptions, that's fine, but the AGPL is a better license choice.
[+] [-] tjogin|14 years ago|reply
Sometimes companies who love and contribute to open source just can't use GPL'ed software, for technical reasons, for lawyer reasons, for FUD, etc.
I, for one, think it would be an awful shame for your cool tech to not achieve the adoption it deserves, just because of GPL.
[+] [-] Lazare|14 years ago|reply
1) Ambiguity. A lot of people aren't so much concerned over the license restrictions you have placed on the project, as completely confused over what those restrictions are. The GPL is written in a way which is extremely ambiguous for a JS framework and (partly) as a a result it is a vanishingly rare license in the web framework/JS space. You should spell out your understanding of what the license does and does not allow on your website.
1b) Your second option ("just send us an email") is also full of ambiguity. For good or ill, people in western cultures tend to hate this sort of haggling. A price sheet would be good, or at LEAST some clarification of the type of commercial license you imagine. Are you expecting to charge a flat rate per developer? Per website? Per visitor? Are you looking for revenue sharing deals? If I want to use Meteor for a closed-source app am I looking at the price of a cup of coffee? The price of a steak dinner? The price of a new smartphone? The price of a new car? Also, what protection do I have from you deciding to slash your commercial license costs by 80% after you think over the response you've been getting?
2) I think a lot of the concern is coming not so much from people who want to write closed source commercial apps as from people concerned that the restrictive license will hamper uptake. Everyone wants to get in on the ground floor of the next Rails/Django/Backbone, and to be able to brag in job interviews looking for an expert Meteor dev "sure, I've been using it since version 0.3!" But dual-licensed projects (like ExtJS) tend to have relatively low adoption. If nobody used Meteor, then Meteor's future isn't going to be as bright, and I'm less excited about using it myself. If everyone is using Meteor, then Meteor's future is bright, and it would behove me to learn it ASAP.
[+] [-] alexkam|14 years ago|reply
[+] [-] alecco|14 years ago|reply
Your license is fine. Perhaps you should consider AGPL as it will cover the PHP-hole, too.
Stay strong, don't give in to pressure by people who are sore because their open source free lunch is ending.
(and this being HN this comment will probably be nuked by downvotes)
[+] [-] nkoren|14 years ago|reply
Best of luck with Meteor in any case!
[+] [-] nkoren|14 years ago|reply
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/
[+] [-] mechanical_fish|14 years ago|reply
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.
[+] [-] ajross|14 years ago|reply
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.
[+] [-] ak217|14 years ago|reply
You are sitting on top of a huge stack of free, enterprise-grade software which has sprung up in large part because of the insistence of some of its authors to use GPL. The authors of a little new library that sits on top of it ask that you open source the portion of your product that you derive from it. Not your whole product, not even the whole client-side part of it - a portion of the client-side javascript that you derived from their library.
And your response to this is to whine about it and tell us how they're limiting their user base.
[+] [-] zavulon|14 years ago|reply
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.
[+] [-] angersock|14 years ago|reply
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.
[+] [-] pwpwp|14 years ago|reply
[+] [-] asdfasdf4321|14 years ago|reply
[deleted]
[+] [-] olalonde|14 years ago|reply
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 code. That's a pretty poor incentive since most businesses don't even care about people stealing their Javascript.
In addition, as mentioned in the article, the GPL license makes people feel like they are contributing because they legally have to rather than because they want to give back to the community, which is not a good thing from a psychological point of view[0].
FWIW, I would advise the Meteor team to pick a more permissive license and reconsider their business model. Perhaps they can provide consulting, hosting, job board, certification, etc.?
[0] http://www.youtube.com/watch?v=oV0cbCFGAtU
[+] [-] mistercow|14 years ago|reply
This is very clearly true, yet I know of several GPL libraries whose maintainers believe the opposite. It is very strange.
[+] [-] pbreit|14 years ago|reply
[+] [-] ahoyhere|14 years ago|reply
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.
[+] [-] marcusf|14 years ago|reply
That said, GPL made me look twice. Mainly because client and server are so intertwined, that I assume the entire app would need to be GPL'd to use Meteor without getting a commercial license. Now I've nothing against the dual licens, and paying for a framework that makes us money , but before shopping Meteor around the company it'd be good to have some specifics on what they're thinking in terms of a commercial license model. I hope that's on their priority list. It's hard to motivate investing in something that may later turn out to be prohibitively expensive.
[+] [-] zdw|14 years ago|reply
In Meteor's case, as it's middleware, the LGPL would be the more appropriate license anyway.
I get the feeling that they're searching for business models with Meteor. The most obvious one would be optimized paid hosting ala Heroku...
[+] [-] antoviaque|14 years ago|reply
I'm always amazed by this reaction - ie being ok to use the generosity of others, but refusing to reciprocate.
[+] [-] jasonkester|14 years ago|reply
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 realized they had those two points exactly backwards.
[+] [-] davidw|14 years ago|reply
Also, when they talk about contributing, they don't write about having to sign a copyright assignment, which they must do if they want to continue to own the copyright to the whole thing, and thus be able to dual license it.
Furthermore, "get in touch and we'll write you a commercial license" doesn't sound like something very easy to evaluate, compared to, say, a pricing page. "Well, how much ya got, anyway?"
It is pretty early for them, though, it would appear, so maybe it's much ado about nothing, and as they work things out, they'll make things clearer and/or change the license.
[+] [-] bguthrie|14 years ago|reply
[+] [-] caf|14 years ago|reply
[+] [-] sanxiyn|14 years ago|reply
[+] [-] shawndrost|14 years ago|reply
[+] [-] cek|14 years ago|reply
But now, this has created FUD for us.
It's all so complex and confusing at a time when we really just want to be writing code. Our startup is not far enough along to know for certain what licensing terms make sense.
I can't believe we will be alone in having this reaction. Which is a shame because Meteor had such a chance of being a real big thing.
[+] [-] obituary_latte|14 years ago|reply
Having to worry about not being able to use Meteor in a commercial capacity without knowing the price-point breaks the deal off the bat. I'm a one man team and don't have the time nor resources to swim through legalities and pricing--I need to be writing code.
This isn't to say, though, that if I wanted to do something outside of the scope of a commercial app I wouldn't try Meteor--but who knows when/if that will happen.
[+] [-] woodhull|14 years ago|reply
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.
[+] [-] mindslight|14 years ago|reply
[+] [-] drpancake|14 years ago|reply
[+] [-] clarkevans|14 years ago|reply
[+] [-] chrisrhoden|14 years ago|reply
Imagine if the client side libraries for Meteor end up in the Google CDN. Then you're only distributing your own code and linking against a separately distributed GPL library. Beyond that, you don't even care if the library is actually Meteor, you just care that it has the API that you use, meaning it can't really be suggested that you know you're linking against GPL code.
What about the server/client split? Could you make an argument that they're implementation agnostic to one-another? So why would you need to distribute your server side code just because you distribute your client code? Simple answer is that you don't under the GPL.
[+] [-] rbanffy|14 years ago|reply
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.
[+] [-] eaurouge|14 years ago|reply
[+] [-] pwpwp|14 years ago|reply
http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...
[+] [-] CodeMage|14 years ago|reply
[+] [-] ewang1|14 years ago|reply
[+] [-] stefantalpalaru|14 years ago|reply
[+] [-] madhadron|14 years ago|reply
There are times when BSD license and equivalent are sensible choices. Berkeley was releasing a reference set of source code. Their whole point was to have a common platform that everyone was building off of. Similarly, a BSD licensed reference implementation of TCP/IP back in the day meant that everyone could get the protocol up and running much faster with far fewer inconsistencies. BSD licensing is useful for social engineering.
But for most cases this isn't so. Why would anyone who wrote a JavaScript library and gave it away want to make it easy for someone else to build a company around taking their work, extending it a little, selling it, and giving nothing back other than enough tidbits to keep the community (if any) from getting up in arms? This is what happened to the Lisp machines, and it's exactly why the GPL is the way it is. Businesses have a fiduciary responsibility to maximize shareholder profits. If you're selling software, that means minimizing costs and maximizing income. It is the legal obligation of a company to take any permissively licensed code it can get its hands on and thinks will speed things up, extend it a little, and sell it. My response: if I'm not trying to engineer your behavior, stop leaching off the community and buy your underlying components.
The GPL exists for a reason. Every so often, some cheap bastard complains about it because he can't make a quick buck by ripping someone else off. Tough. That's why it's there. You want to use my work on this? Give me yours in exchange.
[+] [-] Stratoscope|14 years ago|reply
This is not true.
First, not every business is a corporation or has shareholders.
Second, fiduciary responsibility does not require maximizing shareholder value (or profits). This has been explained several times here on HN and elsewhere by people who know much more about it than me. Here's one good explanation and discussion:
http://www.linkedin.com/answers/law-legal/corporate-law/corp...
Excerpt: "...there is no law stating that the purpose of a corporation must be to maximize shareholder return. The corporation’s purpose may be any legal purpose, chosen by the creator and/or the shareholders. There is no requirement of law that profit or the maximization of value or return must be paramount or even on the list of objectives. The overwhelming majority of U.S. corporations have in their articles of incorporation an article stating that the corporation shall have the right to engage in any legal activity."
[+] [-] olov|14 years ago|reply
Using a library (from a program) is actually a prime example of how GPL copyleft spreads from the GPL library into the program.
[+] [-] webjprgm|14 years ago|reply
Sometimes I make a lib that I want to use for myself, proprietary but not profit making. Sometimes I later want to use that library in a consulting project (now it's profit making). In general, I don't know whether all the desired end uses of my code will be commercial, open source, or just simply code I use personally but don't want to release.
(I believe the GPL triggers upon release/distribution of software, right? If I keep my modified version on my local system and don't sell it or ship it then there's no conflict. However, using it on my personal machine to serve up a publicly accessible website, I believe, also triggers it. Since lots of my "personal" code gets used on my personal, non-commercial, web site, I stay away from GPL even when I think I'm never shipping a piece of code.)
[+] [-] rcthompson|14 years ago|reply
Obviously this is not legal advice, and may in fact be the delusional ramblings of someone who has no understanding of the GPL. But please enlighten me if I'm wrong.
[+] [-] alecco|14 years ago|reply
If it were a proprietary license nobody would raise a finger. HN is a very hypocritical community.
[+] [-] 47|14 years ago|reply