Hacker News Reader

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.

They may only need one customer. Ask the folks who sold MySQL to Oracle

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.

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.

>"If you use my code, you have to give me your code"

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

An important point, it's true, but you've gone too far in the other direction. It's more like:

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

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.

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.

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. So, what.

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.

Mojito was released two weeks ago: http://developer.yahoo.com/blogs/ydn/posts/2012/04/yahoo%E2%...

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

Edit: It's released under a BSD license.

Ooops.. I can't believe I missed it. Thanks!

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.

Have you talked to them?