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.
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.
As soon as there is ambiguity there is also legal risk, and attorneys tend to recommend a conservative position. The only way to avoid such ambiguity is to limit yourself to the well proven "crystal clear" GPL use cases. As has been demonstrated in this thread, even those "crystal clear" use cases are often misunderstood by many (proprietary program linking to a GPL library comes to mind).
It helps a lot if the copyright holders clarify their own position, possibly in a license addendum. Like Torvalds did for the Linux kernel (regarding system calls). Now that didn't hinder the whole controversy of proprietary vs GPL kernel modules, of course.
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.
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 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.
Stay strong, don't give in to pressure by people who are sore because their open source free lunch is ending.
I don't disagree with this sentiment, but the dual licensing is somewhat of a two-edged sword. If they're perfectly fine building the entire Meteor stack in house, then a dual licensed commercial/GPL is fine, but if they're trying to encourage me to join a community of contributors to help build the platform then I'm definitely demotivated by the dual-license. Why should I contribute code to them (and presumably sign a CLA since that's the only way they can dual-license my code) if I'm going to have to pay them if I ever want to build a closed source app myself?
I've seen BSD developers switch to GPL because of too many freeloaders were repackaging and selling their code with a minimal frontend without even respecting proper author credit. There was even a counter-rant by Zed Shaw "The Long Beard's Revenge".
There's a growing feeling of discontent with the startup-brogrammer-douchebag subgroup, as it's becoming a significant part of the whole startup scene. IMHE
I can't think of any examples. Can you provide some?
I found both of Zed's essays to be entirely unconvincing and lacking in evidence. A dearth of new open source projects? Really?? He admits that the GPL makes it hard for people to choose to use it which he counter-intuitively prefers. Ugh.
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.
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.)
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.