Meteor meets NoGPL
[I'm one of the Meteor authors.]
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.
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.
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.?
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.
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.
It's quite entertaining to see "Proprietary Software 2.0" developers complaining about finally being affected by a requirement of Free Software.
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.
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.
It's a question of whether a program using Meteor is to be considered a "derived work".
http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...
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.
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.
Original authors have the right to license their code whatever way they please. This kind of article is disgusting.
If it were a proprietary license nobody would raise a finger. HN is a very hypocritical community.
Sencha has used GPL/Commercial License business model successfully.
This is likely irrelevant for the server-side bit, and it remains to be determined if it is for the client-side.
It will hinder contributions if they require attribution, however.
"The basic idea is that the source code is publicly available for people to look at and modify and that it costs nothing to use as long as you’re building a GPL application with it and give out your source code too"
Can anyone confirm whether this is actually accurate? I'm not sure it is...
This has all the makings of a 'KDE vs Gnome'-like battle. For those not around at the time, a quick refresher: KDE was launched to applause and was based on a (then) restrictive Troll Tech license (for its QT library). This restrictive license lead directly to the creation of the Gnome project and so we saw a very promising desktop environment lose momentum and support as community resources were diverted to reinventing the wheel with Gnome (IMHO).
Yes, we have more choice now in the world of Linux desktops, but I still believe hundreds of man years were wasted and the Linux desktop effort set back years, due to Troll Tech's choice of license. Of course, Troll Tech finally realized the error of their ways, but as history clearly shows us, it was too late.
So, does Meteor want to risk being a KDE (or even Svbtle) and have the community praise it for their ideas and invest huge amounts of time reinventing the wheel, or do they want to harness the unstoppable momentum of the developer community?
The real reason permissive licences are preferred is developers are greedy. I know, I'm a developer and I'm greedy. I don't want to admit I'm using other people's code to do my work. I want to silently include that code and pretend that I did all of it myself and impress people with my amazing programming skills. If I have to buy a license I have fess up, and admit to myself I need their code, whereas if I can just use it freely there isn't that moral barrier to cross.
LoseThos is the only public domain 64-bit OS.
God says... C:\LoseThos\www.losethos.com\text\QUIX.TXT
leave behind me the name of a madman; for though I have been one, I would not that the fact should be made plainer at my death. Call in to me, my dear, my good friends the curate, the bachelor Samson Carrasco, and Master Nicholas the barber, for I wish to confess and make my will." But his niece was saved the trouble by the entrance of the three. The instant Don Quixote saw them he exclaimed, "Good news for you, good sirs, that I am no longer Don Quixote of La Mancha, but Alonso Quixano, whose way o