Meteor meets NoGPL • Hacker News Board

Re: Meteor meets NoGPL

#111

Post by lftl » Fri, Apr 13, 2012, 7:56 PM UTC

alecco wrote: post #102

debergalis wrote: post #76

[I'm one of the Meteor authors.] 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.f…

EDIT: tptacek on AGPL http://news.ycombinator.com/item?id=1273231 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)

Stay strong, don't give in to pressure by people who are sore because their open source free lunch is ending.

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?

Re: Meteor meets NoGPL

#112

Post by WiseWeasel » Fri, Apr 13, 2012, 8:12 PM UTC

ajross wrote: post #106

WiseWeasel wrote: post #101

Earlier quoted context omitted.

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…

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.

Re: Meteor meets NoGPL

#113

Post by alecco » Fri, Apr 13, 2012, 8:18 PM UTC

lftl wrote: post #111

alecco wrote: post #102

Earlier quoted context omitted.

EDIT: tptacek on AGPL http://news.ycombinator.com/item?id=1273231 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)

Stay strong, don't give in to pressure by people who are sore because their open source free lunch is ending. 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…

Yep. That's why I recommended them to consider AGPL.

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

Re: Meteor meets NoGPL

#114

Post by ajross » Fri, Apr 13, 2012, 8:30 PM UTC

WiseWeasel wrote: post #112

ajross wrote: post #106

Earlier quoted context omitted.

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…

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.

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.

Re: Meteor meets NoGPL

#115

Post by Lazare » Fri, Apr 13, 2012, 9:24 PM UTC

debergalis wrote: post #76

[I'm one of the Meteor authors.] 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.f…

I completely understand where your coming from. However, I think it's worth stressing that - from what I've seen - there are two major concerns.

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.

Re: Meteor meets NoGPL

#116

Post by Avshalom » Fri, Apr 13, 2012, 9:43 PM UTC

WiseWeasel wrote: post #112

ajross wrote: post #106

Earlier quoted context omitted.

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…

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"

Re: Meteor meets NoGPL

#117

Post by pbreit » Fri, Apr 13, 2012, 9:57 PM UTC

alecco wrote: post #108

pbreit wrote: post #105

Earlier quoted context omitted.

I downvoted. "Your license is fine" and "open source free lunch is ending" don't seem well-supported by evidence.

Edit: read this first http://zedshaw.com/essays/why_i_gpl.html 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…

I can't think of any examples. Can you provide some?

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.

Re: Meteor meets NoGPL

#118

Post by WiseWeasel » Fri, Apr 13, 2012, 10:56 PM UTC

Avshalom wrote: post #116

WiseWeasel wrote: post #112

Earlier quoted context omitted.

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.

Re: Meteor meets NoGPL

#119

Post by streptomycin » Sat, Apr 14, 2012, 3:05 AM UTC

zmoazeni wrote: post #55

pcc wrote: post #29

Earlier quoted context omitted.

Yes generally you do. But you are only obligated to make source available to parties to whom you distribute the binaries you've built. 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 per…

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

> GPLv2 doesn't require source in this case and AGPL does?

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

Re: Meteor meets NoGPL

#120

Post by Lazare » Sat, Apr 14, 2012, 4:22 AM UTC

zmoazeni wrote: post #55

pcc wrote: post #29

Earlier quoted context omitted.

Yes generally you do. But you are only obligated to make source available to parties to whom you distribute the binaries you've built. 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 per…

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

If your application lives on your own server, and only static HTML/CSS is served to clients, then under the letter of the GPL no "distribution" has taken place, and you do not need to make your source code publicly available[1]. This is known as the "ASP loophole".

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.