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.
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 perhaps less clear-cut.
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.
For what it's worth, Larry Rosen argues that use of a unmodified GPL'd work, as specified in its API, doesn't necessarily create a derived work.
In my opinion, this question won't ever be put to rest since it's about specific cases, law and human interpretation. It matters quite a bit about what the GPL'd work is, what the application is that uses it, how they are related, and the public intent of both parties. While some lines may form in the future, the boundary of safe use itself will always be a bit blurry.
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).
Yes, you do. From memory there's one get-out: if there are non-GPL products which would be drop-in replacements for the user, the GPL isn't contagious.
Not quite. What you are probably remembering is this (or something derived from this).
1. Someone wrote a program. It needed to use an arbitrary precision math library, and it needed to use a freely distributable but closed source library.
2. This program was distributed in source form. In the source code there were #ifdefs to allow it to be built to use either of the two most common arbitrary precision math libraries. One of these was under a BSD license and one was under GPL.
3. Many systems did not have either math library preinstalled, so someone who wanted to build this program on those would have to go download whichever math library they decided to use.
4. Stallman claimed that distributing the program induced people to download the math libraries, and since one of the libraries was GPL, the program was inducing distribution of GPL code, and so itself must be placed under GPL.
5. The author of the program wrote a new math library that was just a wrapper for the BSD library, but that provided the same interface as the GPL library. Now people who chose to build the program with the build option to use the GPL library could successfully build by using this new non-GPL library. Since the source code no longer contained a build option that necessarily induced those electing it to go and download GPL code, Stallman was satisfied.
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.
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).
I agree that the poster only has a superficial understanding of the GPL. Interestingly in the case of Wordpress themes the Software Freedom Law Center has argued that these are derivative works, even though one could argue that these merely use a API cf http://wordpress.org/news/2009/07/themes-are-gpl-too/
http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...