Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twenty questions about the GPL

jacobian.org

Post reply on HN
Print view View original

51–60 of 83 posts

Re: Twenty questions about the GPL

#51

Post by callahad »

vinutheraj wrote: post #49
callahad wrote: post #23

Quick attempt to answer these based on my understanding of the GPL, and just a quick cursory skim of version 3. I am not a lawyer. [Edit: It seems like my answers to the first few are a bit contentious and should really be "it depends"; see comments below.] 1. Yes, by using foo.py as a library, your bar.py must also be GPL'd. This would be different were foo.py under the Lesser GPL. 2. Not shipping foo.py does not ch…

Do you mean that if you call any function which is part of a GPL'd library then consequentially your work is a derivative. Going by that logic can anything running on Linux be a non-GPL'd commercial product ?! I am really confused right now !

Not quite -- the GPL makes exceptions for that in Section 1: "However, [the "Corresponding Source"] does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in [generating, installing, running, or modifying the work] but which are not part of the work."

Basically, system stuff is exempt.

But you're right to be confused. If bright, prominent developers like jacobian and jnoller can't definitively answer these questions, then there's a problem with the implementation of either the GPL or the US legal system. After all, if the developers themselves can't fully grok the GPL, then who is it for?

Re: Twenty questions about the GPL

#52

Post by jmillikin »

tptacek wrote: post #45
blasdel wrote: post #5

Jacob brings up a point I haven't seen clearly expressed before -- the GPL's design directly leads to questions like these (now more than ever with Python/Ruby and Javascript), but the FSF not only does not provide clear or useful answers, there is no mechanism for arriving at decent answers . The problem with the GPL is not really the evangelical copyleft (as annoying as those people can be), the problem is that it'…

The complexity is a feature. Simply put: if you want to work in the open, noncommercially, with maximal sharing, use something other than GPL. If you ever intend to commercialize your work, use GPL. GPL's complexities are a problem for downstream developers, not for the author. That's essentially what you want if you're doing the Open Source / Commercial dual license play.

The complexity is a feature. Simply put: if you want to work in the open, noncommercially, with maximal sharing, use something other than GPL. If you ever intend to commercialize your work, use GPL.

I disagree. All of my work is under the GPL, not out of any concern with commercial use, but to ensure that any users have the same rights to the code as I do. The complexity of the GPL is undesirable and unwanted, though currently necessary.

I used to use the BSD license for my personal projects, under the reasoning that having the source "somewhere out there" would be enough. Then somebody modified my work and passed it on to users without the source. It was a very minor project, and there was no legitimate reason why he couldn't have provided the modified source to his users. After he stopped supporting it, the whole mess was dumped in my lap, with several miserable people wondering why I couldn't help support their "BSD-licensed" software.

The fundamental difference between the BSD/MIT and GPL modes of thought is in whose rights are more important, the developer or the user.

Re: Twenty questions about the GPL

#53

Post by wmf »

jballanc wrote: post #29
davidw wrote: post #20

Earlier quoted context omitted.

> Another option is to operate in reasonably good faith, try to observe the "spirit" of the GPL, and hope that you will not be the target of legal action. And talk with the copyright holder of the software you're using! It's a good idea in any case, and will probably go a long ways towards getting an idea of what they're comfortable with, and what they think their rights are under that license.

If we're going to go with "spirit", why not use the less restrictive license without the potentially scary legal ramifications for large company X? That is, can you tell me why: -- Here's this GPL licensed code. Go ahead and use it, and so long as you keep with the "spirit" of open source, I won't bother suing you. When I die, however, and the executors of my estate notice that they now control copyright on this GPL'…

The spirit of the GPL and BSD licenses are different, especially for libraries (ignoring people who accidentally use GPL instead of LGPL).

Re: Twenty questions about the GPL

#54

Post by wmf »

vinutheraj wrote: post #49
callahad wrote: post #23

Quick attempt to answer these based on my understanding of the GPL, and just a quick cursory skim of version 3. I am not a lawyer. [Edit: It seems like my answers to the first few are a bit contentious and should really be "it depends"; see comments below.] 1. Yes, by using foo.py as a library, your bar.py must also be GPL'd. This would be different were foo.py under the Lesser GPL. 2. Not shipping foo.py does not ch…

Do you mean that if you call any function which is part of a GPL'd library then consequentially your work is a derivative. Going by that logic can anything running on Linux be a non-GPL'd commercial product ?! I am really confused right now !

Linux made an exception to the GPL so that Linux programs don't have to be GPLed.

Re: Twenty questions about the GPL

#55

Post by cschwarm »

callahad wrote: post #23

Quick attempt to answer these based on my understanding of the GPL, and just a quick cursory skim of version 3. I am not a lawyer. [Edit: It seems like my answers to the first few are a bit contentious and should really be "it depends"; see comments below.] 1. Yes, by using foo.py as a library, your bar.py must also be GPL'd. This would be different were foo.py under the Lesser GPL. 2. Not shipping foo.py does not ch…

> 2. Not shipping foo.py does not change the answer to #1; you still depend on it, thus your work still counts as a derivative.

I don't know whether your answers are correct but you should not use the term "derivative" or "derivative work". It's a rather clear legal term. The GPL3 does not use that term, anymore.

In fact, if we would be arguing about a derivative work in the copyright sense, your answer to 2 and 3 (and depending on the circumstances also 1) would be wrong (with the usual disclaimer IANAL).

A software B that uses a library A by "loose" linking does not constitute a derivative work. Courts in the US have develop a test for that: First, B is a complement to A. Second, it doesn't distribute any of A's code when distributing B. Third, thinking otherwise would chill the market, since no library would be used by anyone anymore, for this would make using a library an infringement of the library owner's copyright.

For further information, see:

http://www.law.washington.edu/lct/swp/Law/derivative.html

Re: Twenty questions about the GPL

#56

Post by jojhbugbt »

jbronn wrote: post #37

Greg Vetter, a former law professor of mine at the University of Houston, has written about the pitfalls of 'infectious' open source licenses such as the GPL. I highly recommend taking a look at his paper on the topic: http://ssrn.com/abstract=585922 Ambiguities in copyright precedent about what actually constitutes a derivative work will continue to vex the GPL for some time. The unfortunate truth is that there are…

>Ambiguities in copyright precedent

Fortunately there are no ambiguities anywhere else in the law, which is why all civil lawsuits are decided in 10mins by a secretary and an intern

Re: Twenty questions about the GPL

#57

Post by durin42 »

gchpaco wrote: post #50
callahad wrote: post #39

Earlier quoted context omitted.

I think that particular area is ripe for further exploration. Especially in the context of Jacob's second and third questions: Does the answer change if foo.py does not ship with bar.py, but nonetheless requires foo.py to function? Does the answer change if foo.py does not ship with bar.py and does not require its presence to function? If GPL foo.py is the only library that can fill that void, then sure, once your ap…

This is actually a very practical question, as IIRC Editline was readline compatible on some levels. What follows is all my hazy recollection. If memory serves, the answer was this, although obviously if you ask RMS you get slightly different answers depending: you have to GPL your code (if you distribute it) if you link to GPL code. If you can plausibly link to several different libraries, not all of which are GPL,…

editline is intended to be API compatible, and has weakened the argument that linking implies work-derivation at least somewhat. As far as I know, nobody has ever been willing to test that theory in court since they'd lose so much political face in the process.

Sometime last year, I saw an article claiming that because of libedit's existence, we could all link against readline from whatever we wanted (or at least that this showed that the dynamic-linking-is-deriving was crap), but I can't find the article now.

Re: Twenty questions about the GPL

#58

Post by brl »

callahad wrote: post #31
callahad wrote: post #23

Quick attempt to answer these based on my understanding of the GPL, and just a quick cursory skim of version 3. I am not a lawyer. [Edit: It seems like my answers to the first few are a bit contentious and should really be "it depends"; see comments below.] 1. Yes, by using foo.py as a library, your bar.py must also be GPL'd. This would be different were foo.py under the Lesser GPL. 2. Not shipping foo.py does not ch…

In summary: There's a very clear-cut answer to #6. The rest are fuzzy.

I don't think there is anything clear about #6. Is bar.js a derivative work of foo.js? Probably not, but nobody knows for sure.

Re: Twenty questions about the GPL

#59

Post by huherto »

jerf wrote: post #40
jbronn wrote: post #37

Greg Vetter, a former law professor of mine at the University of Houston, has written about the pitfalls of 'infectious' open source licenses such as the GPL. I highly recommend taking a look at his paper on the topic: http://ssrn.com/abstract=585922 Ambiguities in copyright precedent about what actually constitutes a derivative work will continue to vex the GPL for some time. The unfortunate truth is that there are…

"Ambiguities in copyright precedent about what actually constitutes a derivative work will continue to vex the GPL for some time." That itself is a problem that basically stems from this question: What is the legal definition of "one program"? If that's too hard, what is the technical definition of "one program"? I can't answer that. I've thought about it a lot, and it's just unanswerable. You can only construct one…

So perhapse the GPL shouldn't be used outside of the pure-C environment. Or the FSF should be forced to make the definitions for new environments.

Re: Twenty questions about the GPL

#60

Post by brl »

kingkilr wrote: post #13
blasdel wrote: post #5

Jacob brings up a point I haven't seen clearly expressed before -- the GPL's design directly leads to questions like these (now more than ever with Python/Ruby and Javascript), but the FSF not only does not provide clear or useful answers, there is no mechanism for arriving at decent answers . The problem with the GPL is not really the evangelical copyleft (as annoying as those people can be), the problem is that it'…

The FSF provides an opinion on some of these questions, unfortunately their opinion, that any import or dynamic linking triggers the GPL, a) has never been tested in court, ever (unlike for static linking), and b) is often not matched by the users of the GPL, such as the famed disagreement between RMS and Linus Torvalds with regard to whether Linux in it's current form complies with the GPL.

c) Does not matter.

The FSF does not get to write copyright law and decide what is or is not a derivative work.

Post reply on HN