5 ms·

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 s

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.

regularfry 14y ago
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.
- tzs 14y ago
  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.
pcc 14y ago
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.
- zmoazeni 14y ago
  (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?
  - streptomycin 14y ago
    > 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.
  - Lazare 14y ago
    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.
clarkevans 14y ago
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.
tbrownaw 14y ago
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).

regularfry 14y ago

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.

tzs 14y ago
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.

pcc 14y ago

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.

zmoazeni 14y ago
(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?
- streptomycin 14y ago
  > 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.
- Lazare 14y ago
  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.

clarkevans 14y ago

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.

tbrownaw 14y ago

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