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

Meteor meets NoGPL

blog.lassus.se

Post reply on HN
Print view View original

61–70 of 121 posts

Re: Meteor meets NoGPL

#61

Post by mechanical_fish »

nkoren wrote: post #38

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 co…

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.

Re: Meteor meets NoGPL

#62

Post by ak217 »

nkoren wrote: post #38

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 co…

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.

Re: Meteor meets NoGPL

#63

Post by ewang1 »

pwpwp wrote: post #5

It's a question of whether a program using Meteor is to be considered a "derived work". http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...

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.

Re: Meteor meets NoGPL

#65

Post by cek »

We started digging into Meteor this week (we are using Node.js with express/LazyBoy etc... now) and were really excited about it.

But now, this has created FUD for us.

It's all so complex and confusing at a time when we really just want to be writing code. Our startup is not far enough along to know for certain what licensing terms make sense.

I can't believe we will be alone in having this reaction. Which is a shame because Meteor had such a chance of being a real big thing.

Re: Meteor meets NoGPL

#66

Post by tbrownaw »

CodeMage wrote: post #11
pwpwp wrote: post #5

It's a question of whether a program using Meteor is to be considered a "derived work". http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...

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

Re: Meteor meets NoGPL

#67

Post by nkoren »

ak217 wrote: post #62
nkoren wrote: post #38

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 co…

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 par…

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.

Re: Meteor meets NoGPL

#68

Post by nkoren »

mechanical_fish wrote: post #61
nkoren wrote: post #38

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 co…

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…

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.

Re: Meteor meets NoGPL

#69

Post by ajross »

nkoren wrote: post #68
mechanical_fish wrote: post #61

Earlier quoted context omitted.

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…

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…

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?

Re: Meteor meets NoGPL

#70

Post by markh »

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?

Post reply on HN