Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Meteor, a realtime JavaScript framework

meteor.com

Post reply on HN
Print view View original

241–250 of 350 posts

Re: Show HN: Meteor, a realtime JavaScript framework

#242

Post by dspillett »

zavulon wrote: post #235
AdleyEskridge wrote: post #168

Earlier quoted context omitted.

This looks fantastic. I genuinely got giddy watching the screencast! If I were to use Meteor for a partially closed source app earning around $1000 per month, how much could I expect to pay you? From the FAQ: > If the GPL doesn't work for your project, get in touch (contact@meteor.com) and we will write you a commercial license to your specifications.

I love everything about Meteor so far, except for this. This is no way to answer such an important question that most potential users will have - let's face it, there's a lot of people who will want to use this for open source, but a lot more who will want to use this for commercial apps. To ensure Meteor's wide-spread acceptance, you need to clearly answer this question on FAQ page, and not with "we need to have a c…

A great many things are sold this way, and it is sometimes unavoidable. Commercial projects tend to have a wide range of requirements from a licensing point of view so if they spent time drawing up a full commercial license they would end up having to rearrange half or more of it for the first commercial client that came along anyway. They could spend time drawing up many license templates (world wide, X,000 users, X server, ...) and pricing plans with many combinations of support and development agreements to try cover the bases - or they could spend more time coding.

Their preference is that the library be used under the GPL. That is their choice and it is a fair enough choice. But they also acknowledge that some entities can't accept that for one reason or another, and are willing to be flexible. Very flexible: instead of saying "this is our commercial license, deal with it" they have said "tell us what you need, and we'll see what we can do".

Re: Show HN: Meteor, a realtime JavaScript framework

#243

Post by benmmurphy »

bbayer wrote: post #167
chrismealy wrote: post #119

"In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node." So node's not a cancer now?

+1, what about performance? Does this mean all server will be blocked while doing IO?

I thought they were using fibers (https://github.com/laverdet/node-fibers) so much more scalable than threads but slightly worse performance than callbacks

Re: Show HN: Meteor, a realtime JavaScript framework

#244

Post by skore »

aaronblohowiak wrote: post #46
skore wrote: post #41

Earlier quoted context omitted.

[[citation needed]]. From what I remember, the FSF is pretty consistent in saying that deriving from GPL code is derived work. If your linking constitutes a derivation (a common example would be a database handler that you adapt to your application after you've loaded it) then it is a derivation. If you just loosely call it, it is not.

Golden, Bernard (2005), "Chapter 3. Open Source Risks", Succeeding with Open Source, Addison-Wesley, p. 44, ISBN 9780321268532 You appear to be confusing GPL with the "GPL With Linking Exception" https://en.wikipedia.org/wiki/GPL_linking_exception

It is possible for a piece of software to rely on the output of another piece of software without being derivative. Hell, that's basically how any interface in the world works.

As the wikipedia article on the GPL notes, the problem is not so much the GPL, but how derivative work is not that well pinned down in copyright law itself. That it appears ambiguous in the GPL is a result of that. My rule of thumb is to approach it from the angle of "what is the software worth if you take out what is linked?" - If the software can function without the linked code, it may not be derivative, but the actual question is whether it is useful without the linked code. Whether it carries out the tasks that the user needs the software for without the linked code.

To me, it's more of a social question of how much the linkee is indebted to the linked.

So no, I don't think I am confusing the two.

https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin...

Re: Show HN: Meteor, a realtime JavaScript framework

#245

Post by kragen »

ig1 wrote: post #213
kragen wrote: post #114

Earlier quoted context omitted.

It kills its usefulness for proprietary software , unless you're willing to pay the Meteor guys whatever they ask for a license. But I'd like to point out that there's actually a lot of software out there that isn't proprietary, and Meteor looks like a dramatically better way to write it.

Let's assume you have Meteor on your website: Want to use google analytics ? - nope you can't. Want to offer third-party oauth login ? - nope you can't. Want to use like/tweet/+1 buttons ? - nope you can't. GPL essentially means your website can't have anything on the client-side which is not GPL compatible. And from reading the Meteor guys website that's not what they intend, their choice of GPL was to ensure and ch…

It's not quite that black-and-white. Why do you think OAuth is prevented, for example? You don't have to include JS code from Twitter in your page to enable OAuth logins to Twitter. Similarly, Facebook Like buttons run in a separate iframe; you can make a clear argument that they are a separate program from your site.

You're probably right about Google Analytics.

It may be true that they adopted the GPL without carefully thinking it over, or it could be a deliberate choice, as with GhostScript — whose commercial customers are mostly printer companies, who are willing to pay for a license so they don't have to send their printer firmware source code to all their buyers, which the GPL would require.

Sencha is another JS toolkit using the GPL to encourage people to buy licenses for proprietary use.

Re: Show HN: Meteor, a realtime JavaScript framework

#246

Post by jmarinez »

grannyg00se wrote: post #226
micheljansen wrote: post #208

My first impression of this: wow. If Meteor is all it appears to be, this is nothing short of revolutionary. My second reaction: what happens when the magic ends? When I was new to Rails, I really loved how easy it was to get started with scaffolding, a nice DSL for specifying relations, nifty form helpers. However, the first time I veered a little off the golden path and wanted to do something a little more complica…

I'd like to see some additional detail on this particular idea: "In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. " Seems one of Node's primary style advantages (async non-blocking style) has been eschewed.

Fibers take care of the "callback pyramid of doom" and makes it easier to write thick logic layers. However, it still would have the fairness and starvation issues that Node has with callbacks. It's still single-threaded and non-preemptive like "stock" node. I wonder how dependent Meteor is on Node? In other words, why Node? Is it for Node module compatibility? If it isn't, I'd love to see Meteor running on something else. I bet this thing would really fly on a lua backend with coroutines. Luvit.io?

Re: Show HN: Meteor, a realtime JavaScript framework

#247

Post by ceejayoz »

ig1 wrote: post #213
kragen wrote: post #114

Earlier quoted context omitted.

It kills its usefulness for proprietary software , unless you're willing to pay the Meteor guys whatever they ask for a license. But I'd like to point out that there's actually a lot of software out there that isn't proprietary, and Meteor looks like a dramatically better way to write it.

Let's assume you have Meteor on your website: Want to use google analytics ? - nope you can't. Want to offer third-party oauth login ? - nope you can't. Want to use like/tweet/+1 buttons ? - nope you can't. GPL essentially means your website can't have anything on the client-side which is not GPL compatible. And from reading the Meteor guys website that's not what they intend, their choice of GPL was to ensure and ch…

> GPL essentially means your website can't have anything on the client-side which is not GPL compatible.

That's a fairly insane contention. The GPL license document itself would violate that.

> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Post reply on HN