Live data from Hacker News

Twenty questions about the GPL

jacobian.org

31–40 of 83 posts

Re: Twenty questions about the GPL

#31

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.

Re: Twenty questions about the GPL

#32
post #19

Earlier quoted context omitted.

"...and hope that you will not be the target of legal action." I think that's a hope that I, jacob and many others are not willing to sign up to.

I've found that most of the fear comes from the misconception that the GPL could force your code open against your wishes. In the US, that's simply not possible. Check out this article on Groklaw ("The GPL is a License, Not a Contract, Which is Why the Sky Isn't Falling") for more: http://www.groklaw.net/article.php?story=20031214210634851 I've found it helpful to clear up that misconception, point to past infraction…

I've never thought the fear was that proprietary code would be forced to have its source opened. I was under the impression that the fear for large companies has more to do with injunctions on sale and/or distribution as a result of license violation. Try to tell Microsoft that they can't sell Windows for the next week and see what they think of that...

Re: Twenty questions about the GPL

#33

This would be a much more interesting article if the author had at least tried to get answers to his questions (perhaps from the GNU foundation or the Software Freedom Law Center, etc) and included that with his questions. That would have been an interesting article, and possibly useful to hackers and software entrepreneurs. As it is, I'm surprised and disappointed that an article with so little substance has made it…

HN is largely anti-GPL. You are being dowmodded for that reason.

Re: Twenty questions about the GPL

#34
post #16

Earlier quoted context omitted.

GNU Readline is a GPL library controlled by the FSF, that implements basic interactive line editing. For a long time it was more or less the only one. RMS believes that if you link with it in any way, even as a compile-time default-off option, your product must be GPL: http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/doc/... As a result, for years and years , non-GPL (not just closed-source, BSD too) programs…

even as a compile-time default-off option You're glossing over some of the complexities of this rather interesting situation. In particular, the guy who wanted to be able to make it a compile-time option had a program that would do basically nothing without readline , and you had to enable it for the program to work. A similar issue is with two-part programs; one part non-GPL, one part GPL, which are left up to the u…

In particular, the guy who wanted to be able to make it a compile-time option had a program that would do basically nothing without readline

That's not true. If you read the story you'll see that the guy had a working program for years before he used readline. The use of readline only improved an already working program. Not to mention, the program in question was a language implementation and readline had nothing to do with it. It was a user interface perk.

At one point he said he'd distribute a working program without readline or readline support even enabled by default and leave it up to the user to configure it. It was only going to have an interface to readline without including any readline code. He was told he couldn't even do that.

In the end he chose to GPL the entire language implementation. To him, it probably didn't make a difference what the license was and it was easier than replacing readline. Personally, I would have replaced it with a BSD-licensed alternative just out of spite given the way the whole thing was approached. The line about how a judge wouldn't be convinced the program didn't violate the GPL read like a thinly veiled threat to me.

Re: Twenty questions about the GPL

#35
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'…

Like I said, talk with the person/people/org, and understand their situation. I've talked with some people who are real GPL zealots, who are really not interested in the idea of proprietary software at all, and you can take their code as is, or leave it. Others are willing to work with you when they see some potential advantages to a more liberal license. A lot of people, probably the majority, just don't want to feel "ripped off", so if you're using their software, you should respect the license (it's not that hard with the GPL) both in the spirit (which may vary from person to person) and in the letter, and see if there's a way to come to an agreement if things don't quite match. And sometimes people in this latter category don't understand the GPL well either, so talking with them is likely to smooth things over in any case, if what you're using is something important to your business.

And consider that in the worst case, you're no worse off than if you encountered a proprietary-licensed library that was too expensive for you to use.

Re: Twenty questions about the GPL

#36

Earlier quoted context omitted.

even as a compile-time default-off option You're glossing over some of the complexities of this rather interesting situation. In particular, the guy who wanted to be able to make it a compile-time option had a program that would do basically nothing without readline , and you had to enable it for the program to work. A similar issue is with two-part programs; one part non-GPL, one part GPL, which are left up to the u…

What if there was a proof-of-concept of a forthcoming replacement for the GPL'd part, and it happened to be vaporware? I'm not too familiar with all of this.

The farther you get into the gray area, the less of a clear answer you can get, because it becomes more than anything else an issue of which way the judge rules. This is why generally it's a good idea to err on the side of caution with any type of software license.

Re: Twenty questions about the GPL

#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 no clear legal answers to many of these questions -- and that's kind of the point that Jacob is making in asking them in the first place.

Re: Twenty questions about the GPL

#38
post #34

Earlier quoted context omitted.

even as a compile-time default-off option You're glossing over some of the complexities of this rather interesting situation. In particular, the guy who wanted to be able to make it a compile-time option had a program that would do basically nothing without readline , and you had to enable it for the program to work. A similar issue is with two-part programs; one part non-GPL, one part GPL, which are left up to the u…

In particular, the guy who wanted to be able to make it a compile-time option had a program that would do basically nothing without readline That's not true. If you read the story you'll see that the guy had a working program for years before he used readline. The use of readline only improved an already working program. Not to mention, the program in question was a language implementation and readline had nothing to…

At one point he said he'd distribute a working program without readline or readline support even enabled by default and leave it up to the user to configure it. It was only going to have an interface to readline without including any readline code. He was told he couldn't even do that.

Then RMS was wrong. The SFLC says you're quite allowed to do that, a classic example being ffmpeg, which can be LGPL, GPL, or even non-redistributable depending on what external libraries you link it to on compile-time.

People have to learn that RMS is not God and that just because he says something about the GPL doesn't mean that the lawyers agree.

Re: Twenty questions about the GPL

#39
post #16
post #3

[deleted]

GNU Readline is a GPL library controlled by the FSF, that implements basic interactive line editing. For a long time it was more or less the only one. RMS believes that if you link with it in any way, even as a compile-time default-off option, your product must be GPL: http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/doc/... As a result, for years and years , non-GPL (not just closed-source, BSD too) programs…

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 app runs a code path that takes it through foo.py, it's a derivative work. But what something else could fill that void?

For instance, what would happen if Editline exposed a Readline compatibility layer?

Re: Twenty questions about the GPL

#40
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 if you make some very limiting assumptions. The GPL itself does a decent job of clearly delimiting its boundaries, but only if you are in a pure-C environment. If you actually read the license, it is basically only applicable to such programs, despite its widespread use outside of that language. Even GPLing an emacs lisp module (staying entirely within the FSF's direct interests) is somewhat dubious.

And the general case is just absurd.

Post reply on HN