Live data from Hacker News

Meteor meets NoGPL

blog.lassus.se

11–20 of 121 posts

Re: Meteor meets NoGPL

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

Re: Meteor meets NoGPL

#12
LGPL with a linking exception for platforms that require solid binaries (like iOS, some embedded systems) covers the vast majority of use cases that the "anything but GPL" crowd cares about.

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

Re: Meteor meets NoGPL

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

Re: Meteor meets NoGPL

#14
post #4

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

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.

You're correct that for a server side web project the GPL doesn't make you distribute source since you never distribute the binary. For client side javascript stuff though you ARE distributing the result (minified JS or whatever) so you do have to distribute the original source.

Re: Meteor meets NoGPL

#15
This is likely irrelevant for the server-side bit, and it remains to be determined if it is for the client-side.

It will hinder contributions if they require attribution, however.

Re: Meteor meets NoGPL

#16

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…

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.

Re: Meteor meets NoGPL

#17
post #4

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

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.

AGPL closes the "loophole" for server-side 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.

Re: Meteor meets NoGPL

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

Re: Meteor meets NoGPL

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

Re: Meteor meets NoGPL

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

Post reply on HN