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'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.

The GPL is tricky.

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.

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.

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)

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?

EDIT: you should keep the GPL licence only for patches sent upstream

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 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.

Best of luck with Meteor in any case!

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.

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.

> 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.)

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/

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.

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.

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.

The folks who sold MySQL, sold MySQL to Sun before Sun was bought by Oracle. They were able to sell to Sun because they had a LOT more than one customer using MySQL in the first place.

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.

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.

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.

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.

Good communities are founded on mutual respect and voluntary engagement.

No, the GPL says "If you use my code, you have to let people use yours too"

"If you use my code, you have to share yours under the terms I determine."

It muddies my main point about the relative value of the code in question, however.

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.

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.

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.

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.

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?

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.

On github: https://github.com/yahoo/mojito/

Edit: It's released under a BSD license.

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.

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

This is very clearly true, yet I know of several GPL libraries whose maintainers believe the opposite. It is very strange.

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.

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.

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...

I'm always amazed by this reaction - ie being ok to use the generosity of others, but refusing to reciprocate.

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.

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.

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.

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.

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.

If I don't have a baseline price and I am worried about licensing, I'm not going to spend time trying to fight for a budget to then spend time trying to negotiate a contract--I don't have time.

If I could dev without licensing worries, then I would fight for a budget for things like support and add-ons.

Also, may I ask why you put "writing code" in quotations?

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.

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.

http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...

Typically a web app that generates and serves html, would not be 'distributing' the derivative work, so there would be no source obligation (GPLv2; AGPL etc changes this).

If its a web app that includes client-side js that in turn relies on a particular server-side API, things are perhaps less clear-cut.

Could you clarify? GPLv2 doesn't require source in this case and AGPL does? Or both GPLv2 and AGPL (along with versions) do?

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. :)

[1]: You would be, of course, thumbing your nose at the spirit of the GPL.

Yes, that was the original (and only) motivation for writing the AGPL in the first place.

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.

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).

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.

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.

Heck, I would be surprised if folks like the FSF didn't take that position. "The client and server sides raise different ethical issues, even if they are so closely integrated that they arguably form parts of a single program." -- Stallman himself in [The JavaScript Trap](http://www.gnu.org/philosophy/javascript-trap.html).

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.

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."

Using a library (from a program) is actually a prime example of how GPL copyleft spreads from the GPL library into the program.

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.)

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.

If it were a proprietary license nobody would raise a finger. HN is a very hypocritical community.

It will hinder contributions if they require attribution, however.

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.

Can anyone confirm whether this is actually accurate? I'm not sure it is...

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.

Meteor pushes a lot of code to the client. This most probably constitutes distribution.

See Sencha's take on this: http://www.sencha.com/legal/open-source-faq/

They make money by dual-licensing JS code.

I am fine with attributing others. I have actually done it after paying even when paying removes the need (e.g. glyphicons pro).

it's greed, ego, etc.

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.

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

But then practically all my own current work is open-sourced which probably skews my opinions.