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

91–100 of 121 posts

Re: Meteor meets NoGPL

#91

Post by getsat »

mistercow wrote: post #77
olalonde wrote: post #23

GPL doesn't require you to distribute your server-side code if you are hosting it on your own servers (AGPL does). The client side code does have to be open sourced since it is distributed but Javascript code is pretty worthless without the server-side API, HTML and CSS that goes with it. In other words, all the commercial license does from a business point of view is allow you to sue people who copy your client side…

> GPL doesn't require you to distribute your server-side code if you are hosting it on your own servers This is very clearly true, yet I know of several GPL libraries whose maintainers believe the opposite. It is very strange.

Are they GPL, or AGPL? The AGPL removes the so-called "network service loophole". Unsurprisingly, few projects use it.

Re: Meteor meets NoGPL

#92

Post by zobzu »

nkoren wrote: post #67
ak217 wrote: post #62

Earlier quoted context omitted.

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.

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?

Re: Meteor meets NoGPL

#93

Post by zobzu »

koko775 wrote: post #85
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 think you're turning this too corporate too soon. At this stage your most powerful evangelists will be hobbyists and spare-timers. When I write code, I like to write it open-source. Setting the obviously negative connotation aside, it is objectively true that the GPL code, compiled or no, is a license virus that spreads so fundamentally that linking with non-GPL-compatible code violates the terms. Because the disti…

It's so hypocritical tho.

Obviously you want to release only code that will help you code less in the future (ie: let others maintain feature X for FREE for us; but don't give them what MATTERS)

And that's the main concern with all the anti-GPL folks - that's also the very reason why the GPL exists.

Re: Meteor meets NoGPL

#94

Post by zobzu »

protomyth wrote: post #41
wavephorm wrote: post #28

The real reason permissive licences are preferred is developers are greedy. I know, I'm a developer and I'm greedy. I don't want to admit I'm using other people's code to do my work. I want to silently include that code and pretend that I did all of it myself and impress people with my amazing programming skills. If I have to buy a license I have fess up, and admit to myself I need their code, whereas if I can just u…

It's not greed, it's friction. Developers don't like friction in development and worrying about licensing is a type of friction that requires real money. I want to help them (I contribute $ to a few projects), but I need to know my stuff will work with there's before I go paying. There are few things worse than paying for software, deploying, and finding out you need to switch to something else. I am fine with attrib…

attributing != sharing back

it's greed, ego, etc.

Re: Meteor meets NoGPL

#95

Post by joeshaw »

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…

Lots of people will argue against the GPL on philosophical grounds alone.

I'm going to argue against it based on its ambiguity. Just reading this thread illustrates the problem clearly. In the old days of simple, standalone applications and libraries on a single machine, the obligations of the recipient of the source code was clear: your own code must also be GPL compatibile. With this new model of some of the code existing on the server and some on the client, and the GPL's use of the term "derivative work," it's very unclear to the average programmer what his or her obligations under the license are. Ultimately you as the copyright holder have to enforce your license, and the ambiguity in the meaning of the license, your motivation for choosing the license, and your intentions make things muddled.

If you are simply looking for a "copyleft" license in which people must contribute changes to Meteor back, that's fine, but the LGPL or MPL are probably better license choices.

If you want to ensure that your project is only used for open source applications with case-by-case commercial licensing exceptions, that's fine, but the AGPL is a better license choice.

Re: Meteor meets NoGPL

#96

Post by olov »

stefantalpalaru wrote: post #18
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 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.

You're trying to make a complex issue simple. It's true that scenarios exist where you can use the redistribution-loophole to keep your modifications to a server side GPL program proprietary (Affero GPL was later designed to prevent that).

Meteor's client and server architecture are very tightly intertwined, and both of them are GPL (v2). Given that the GPL is (deliberately) vague in defining the technical details of copyleft, I can't see how it would be unreasonable for an attorney to take the position that the Meteor client and server parts form one program and thus when the client part is redistributed, the server part must be too.

Heck, I would be surprised if folks like the FSF didn't take that position. "The client and server sides raise different ethical issues, even if they are so closely integrated that they arguably form parts of a single program." -- Stallman himself in [The JavaScript Trap](http://www.gnu.org/philosophy/javascript-trap.html).

Re: Meteor meets NoGPL

#97

Post by olov »

madhadron wrote: post #42

Other folks have already pointed out that using a library does not constitute a derivative work, so the author's point is irrelevant anyway. There are times when BSD license and equivalent are sensible choices. Berkeley was releasing a reference set of source code. Their whole point was to have a common platform that everyone was building off of. Similarly, a BSD licensed reference implementation of TCP/IP back in th…

> Other folks have already pointed out that using a library does not constitute a derivative work, so the author's point is irrelevant anyway.

Using a library (from a program) is actually a prime example of how GPL copyleft spreads from the GPL library into the program.

Re: Meteor meets NoGPL

#98

Post by rcthompson »

Am I missing something here? My understanding is that when you use GPL software in your product, you are not required to GPL your own code unless your code and the GPL code are compiled into the same executable that is distributed to the user. Looking at the Meteor website's front page, I don't see anything that suggests it compiles your code and its own coffee into a single executable, so I don't think that using it would require you to GPL anything except possibly any customizations that you make to Meteor itself.

Obviously this is not legal advice, and may in fact be the delusional ramblings of someone who has no understanding of the GPL. But please enlighten me if I'm wrong.

Re: Meteor meets NoGPL

#99

Post by alexkam »

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…

How are you planning to deal with pull requests? i.e. will you require signing CLA (like dojo does http://dojofoundation.org/about/cla )? I assume you are not going to keep commercial and GPL codebases separate, so you need some kind of permission from the contributors that you can re-license/sell their code?

Re: Meteor meets NoGPL

#100

Post by ajross »

WiseWeasel wrote: post #89
ajross wrote: post #57

Earlier quoted context omitted.

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

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.

Post reply on HN