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.
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.)
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 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.
Excuse me, but why are you talking about "threats"? Saying "I wish I could use your product, but I can't" is a threat?
No, Meteor isn't a risk to my business plan, because I wouldn't put a three-day-old framework into my business plan under any circumstances. What I am saying is that I won't ever put a framework which has this license plus an obfuscated pricing model into my business plan, and that makes me sad.
And no, I haven't talked to the Meteor folks. I have no doubt that they're completely lovely people, but really, there's nothing to talk about yet. As explained above. There wouldn't be anything to talk about until after a fairly substantial amount of code had been written. As explained above. And that code won't be written with Meteor, for reasons explained above. If they want to give assurances about the nature of their licensing terms, then there's no reason they can't do so in public.
But... every product that doesn't have a price sticker attached to the box (which includes pretty much every development tool out there) has an "obfuscated pricing model". Are you saying you'd never buy a commercial database product? A RHEL site license? Maybe not, but if so: why are you complaining about the GPL specifically instead of just stating that you won't buy products without fixed pricing?
I'm complaining about the GPL in conjunction with obfuscated pricing. If their pricing were more transparent, I would certainly have less of a problem.
And yes, I know that many products are sold on a negotiated, non-fixed-price basis. I generally do everything possible to avoid buying those products, as that is too often a cover for predatory pricing practices. There are plenty of ways to do sensible price differentiation while still stating your policies clearly.
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 read the comment from nkoren differently and agree. With something like ClearCase or a CAD tool there is a defined licensing model. They aren't going to charge based upon each CAD file generated.
With meteor there is no knowing how the pricing will be without asking first; but nkoren's concern is that they won't know a viable business model until after significant work has gone into development. At that point if nkoren doesn't like the pricing they would have to switch to another framework.
I never got the impression that nkoren was against paying for meteor, just against taking a leap of faith on _any_ system which would require significant investment of time before finding out even a general idea of how the pricing works.
One of the main points is that Meteor supposedly seeks to build a community around their project, and that the GPL is a hindrance to this goal. Without a strong community, a tool such as this might not have much relevance in the future, relative to others which have successfully built a rich ecosystem around themselves.
There are plenty of GPL projects with robust communities though. (Albeit not in the web development space). The same kind of thing was argued c. 1998 when the "Open Source" branding movement started and all the cool projects went with permissive licenses. And it really wasn't correct. GPL projects continue to be very successful a decade and a half later. The apocalypse never came.
So I guess I'm saying that I understand that argument, but I don't buy it. Which side of the argument you land on tends to be colored mostly by your emotional feelings about the GPL (I find as I age that I'm becoming more and more a pinko commie copyleft fanboi, for example), and not really well grounded in practice.
I typically land on the side of pragmatism over idealism, and as a lifelong observer of human behavior and psychology, I would say the argument carries some weight. A project I can start using without even thinking of licensing issues, and grow to become dependent on, is one I'm much more likely to contribute towards, simply out of selfish necessity and convenience.
Sure. But that's only pragmatism in the sense of "I want what's best for me and my project". It's the kind of "pragmatism" that led Andy Rubin to demand rewriting the GPL userspace with a clearly inferior one for Android, for example.
After enough years and enough projects, I find my perspective is broader. The GPL helps more than it hurts. Efforts to explicitly avoid the GPL (not just to use permissive licenses for free software projects -- that's clearly a good thing) tend to hurt more than they help.
How does saying "If you use my code, you have to give me your code" make me want to use it, let alone join your "community"? It seems toxic and coercive to me. It's suggesting that my code is of much lower value than your code, so don't worry about it. This might be correct most of the time, but when it's not, it's a problem.
Good communities are founded on mutual respect and voluntary engagement.
OK, and on reading "toxic and coercive" I just point you back to the point before where I said that the opinion has more to do with our emotional reaction to the license and not any true practical concern. Let's just say that it doesn't seem that way at all to me (I'd tend to use words like "fair" and "sharing", which don't seem so bad) and agree to drop this.
I'm sure there's some element of not wanting to pay money in the original comment, but the commenter clearly stated that one viable option is to make the pricing explicit.
I agree (almost) completely. When the pricing is obfuscated you can't take the risk of building software without knowing how much the license is going to cost you. Where I don't agree is that you can probably talk about pricing before you start coding, while developing your business plan. Hopefully they are flexible enough to have reasonable negotiations even though your business plan is not yet fixed in stone. Ideally the negotiations would simply be them stating a fixed price and a bit of haggling. It's complicated if they want a percentage of profits. But you don't know until you ask.
I find it hard to stomach the attitude of this comment.
And your response to this is to whine about it and tell us how they're limiting their user base.
Actually, if that's what they were asking, then I'd be very happy to comply. But the GPL requires that my ENTIRE product -- anything on the client side -- be GPL'd as well.
The MPL requires that anything derived from their library has to remain open-source. That's great. Totally support it. The GPL, as I understand it, requires that anything used with their library must be open-source. That's a problem.
After reading up on this for a bit, I think I see where you're coming from. It does sound like the GPL treats the entire client side of any given website as a single application, and so use of any GPL-licensed code triggers the requirement to release all client-side code.
With this in mind, the MPL does sound like the better choice. It's still vastly superior to BSD or MIT, since it requires you and me to release any changes we made to the library itself.
What I think this means is that the GPL (or a new successor to it, since Richard Stallman is too much of a curmudgeon) needs to start distinguishing between portions of web applications according to their origin, to enable the various scenarios that are possible when distributing executable code but currently not webapp client-side code.
I don't like GPL. GPL is a religion about how all the software in the world should be free. That's not my religion. Open source is totally different, like the MPL. I am very thankful for all open source projects, but I'm not sure any of them need to be GPL. (could be wrong.)
What I think is "so what".
Most of the software you use is probably open source. That's more than you'd code in your lifetime.
GPL let you keep things in house if you don't distribute. Google does that all the time. A lot of their stuff isn't contributed back.
And heck, it's a BAD thing, but they CAN do it.
Yeah more permission just let companies make more money off free stuff; its only in some rare occasions that they truly contribute back, unless it's GPL and they're forced to use it because they distribute it (although many just go the illegal way)
Now if you don't want GPL and no alternative that is free exists, well you know, code it yourself? Or are the people coding for free supposed to pay your lunch too?
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.
Meteor mixes server- and client-side code, and in general the two sides will interact so intimately that as I understand the GPL, simply separating the server-only code into its own files won't be enough to avoid the requirement to provide source code for it. The Meteor developers might have a different understanding of this, though.
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.
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.
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.
I think the obnoxious part is not being entirely upfront and clear about what you're looking to do. Sencha make no secret of the fact they're a business, with Meteor you need to infer it from a vaguely worded FAQ point and the licence type.
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.)
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.
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.
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.
If your application lives on your own server, and only static HTML/CSS is served to clients, then under the letter of the GPL no "distribution" has taken place, and you do not need to make your source code publicly available. This is known as the "ASP loophole".
The AGPL was specifically developed to close this ASP loophole, and a app on your own server, again only serving static HTML/CSS to clients, would require you to make the source code available under the AGPL.
Now, the big question is, what about apps that serve up JS to clients? Again, the spirit of the GPL is clear here: You are distributing GPL code to clients, and must make the source code for everything (client, server, build scripts, unit tests, media assets, everything) available. But unlike in the static example, the letter of the GPL is very unclear.
Many people - including Sencha, who have built an entire business around this interpretation - believe that webapps with significant client-side components are "distributed" under the terms of the GPL, and thus the ASP loophole does not exist for JS-heavy GPL-licensed webapps; the source code must be made available, and that this requirement extends to both the client and server-side codebases.
Other people have argued that - contra Sencha - the GPL only applies to the client code of webapps. Still others have argued that the ASP loophole does still exist for GPL-licensed JS applications. Other people argue that the somewhat archaic terms used in the GPL don't even apply to modern interpreted languages. It's even been suggested that you can't even legally visit a website using GPL JS on a non-free webbrowser like IE, nor use Google Analytics on any GPLed website. The whole thing is, frankly, a royal mess.
Anyhow, coming back to Meteor: Ultimately a court's interpretation will be binding, but no court has ruled on this issue. Until then, you're probably safest following the wishes of the author. If - as with Sencha - the author says that there is no ASP loophole it's safest (not to mention morally correct) to follow their wishes. In this case, the Meteor dev's appear to be following an interpretation very close to Sencha's. So the safe/moral answer is - at least until there's more clarification - assume that for any Meteor app that the GPL and AGPL are effectively the same. :)
: You would be, of course, thumbing your nose at the spirit of the GPL.
For what it's worth, Larry Rosen argues that use of a unmodified GPL'd work, as specified in its API, doesn't necessarily create a derived work.
In my opinion, this question won't ever be put to rest since it's about specific cases, law and human interpretation. It matters quite a bit about what the GPL'd work is, what the application is that uses it, how they are related, and the public intent of both parties. While some lines may form in the future, the boundary of safe use itself will always be a bit blurry.
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?
Yes, because the FSF's FAQ says that you do. Trying to argue that copyright law doesn't actually allow them to indiscriminately demand this would be expensive and would annoy lots of people, so is probably a bad idea regardless of that you'd likely win (unless you're doing it specifically to prove a point).
Not quite. What you are probably remembering is this (or something derived from this).
1. Someone wrote a program. It needed to use an arbitrary precision math library, and it needed to use a freely distributable but closed source library.
2. This program was distributed in source form. In the source code there were #ifdefs to allow it to be built to use either of the two most common arbitrary precision math libraries. One of these was under a BSD license and one was under GPL.
3. Many systems did not have either math library preinstalled, so someone who wanted to build this program on those would have to go download whichever math library they decided to use.
4. Stallman claimed that distributing the program induced people to download the math libraries, and since one of the libraries was GPL, the program was inducing distribution of GPL code, and so itself must be placed under GPL.
5. The author of the program wrote a new math library that was just a wrapper for the BSD library, but that provided the same interface as the GPL library. Now people who chose to build the program with the build option to use the GPL library could successfully build by using this new non-GPL library. Since the source code no longer contained a build option that necessarily induced those electing it to go and download GPL code, Stallman was satisfied.
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.
You're trying to make a complex issue simple. It's true that scenarios exist where you can use the redistribution-loophole to keep your modifications to a server side GPL program proprietary (Affero GPL was later designed to prevent that).
Meteor's client and server architecture are very tightly intertwined, and both of them are GPL (v2). Given that the GPL is (deliberately) vague in defining the technical details of copyleft, I can't see how it would be unreasonable for an attorney to take the position that the Meteor client and server parts form one program and thus when the client part is redistributed, the server part must be too.
I agree that the poster only has a superficial understanding of the GPL. Interestingly in the case of Wordpress themes the Software Freedom Law Center has argued that these are derivative works, even though one could argue that these merely use a API cf http://wordpress.org/news/2009/07/themes-are-gpl-too/
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.
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.
The license difference is why you're aware of so many places that Linux is used. It's hard to miss a blob of text as big as the GPL.
There are a lot of boxes running FreeBSD internally which you never hear about. We try to convince vendors that it's ok to talk publicly about using FreeBSD, but an awful lot of them consider it to be "secret sauce" which they don't want their competitors to hear about.
"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...
Not entirely. If you're building an application based on GPL licensed code, which is not handed over to the an other party, you're not required to handover any adjustments you've made in the GPL licensed code. That's what is referred to as the 'Services as a loophole' construct (ab)used in the GPL. See also this 2007 article by Tim O'Reilly: http://radar.oreilly.com/2007/07/the-gpl-and-software-as-a-s...
Btw, The AGPL tries to prevent this loophole and does require you to share adjustments made by you on AGPL licensed code even if your only using the software as a service and the other party will not receive the application/code.
I've been reading up on GPL because I know little about the nuances, but I think you only need to GPL and provide the source code if you distribute it to others. Web seems tricky for GPL, but I thought that was the purpose of AGPL. Please correct me it I am wrong.
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.
It's not greed, it's friction. Developers don't like friction in development and worrying about licensing is a type of friction that requires real money. I want to help them (I contribute $ to a few projects), but I need to know my stuff will work with there's before I go paying. There are few things worse than paying for software, deploying, and finding out you need to switch to something else.
I am fine with attributing others. I have actually done it after paying even when paying removes the need (e.g. glyphicons pro).
I'll share back too if it I have some improvement (I am going to test in on my own site first).
Greed is actually a very poor reason for not sharing back. It actually costs more money to maintain a forked code base than contributing the change back and getting it maintained by everyone. It is also fairly stupid to hide what software you are using from a recruitment point of view.
I prefer the BSD / MIT licenses because the sharing occurs on my schedule, less stress, and less friction. I like doing things because it is right and not because I have a lawyer at my door.
You got it reverse. Most permissive licenses need attribution (in form of leaving the original header comment etc) which lets the whole world know that you are using the component. A commercial license gives you complete anonymity (most let you completely change the source code) except for the charge on your credit card bill.
And I don't think its greed. Not many applications on any platform gets written completely from scratch without using other libraries.
Most permissive licenses need attribution (in form of leaving the
original header comment etc) which lets the whole world know
If the code is being used for commercial and propriety purposes then the code is never seen, never attributed. Attribution in the form of source code comments is really only valuable in other open source projects.
As a developer I'm just the opposite - I want to give as much attribution as possible from both personal (acknowledge the people who actually did the work, feel-good-about-being-part-of-a-community) and practical standpoints (demonstrating the components come from external projects known to other people rather than part of a personal codebase that only I'm intimately familiar with that the client always has to rely on me to maintain).
But then practically all my own current work is open-sourced which probably skews my opinions.