Live data from Hacker News

Twenty questions about the GPL

jacobian.org

71–80 of 83 posts

Re: Twenty questions about the GPL

#71
It's universal that you can't both have and eat the cake. 99% of problems with GPL arise from the fact that companies and individuals want exactly that.

GPL is more indifferent to many real-world aspects than people assume it is.

It is an idealistic license and it only cares about the right to use the program and the availability of source code, to ensure free use and reuse of the program. This ideal is rather neutral towards any commercial and business aspects: it only conflicts with some of the established practices and beliefs of the current business world.

GPL does not intend to compete or lock-out other software while that may indeed happen if you're playing a different game and holding tightly on to contradicting views of what you think is important.

In reality, there are no other limitations in GPL than that effectively no single author or distributor can't enforce control over or killing the software.

For companies, there are two possible outcomes:

1) secrecy of the company source code is more valuable. Conclusion: there's no rational reason to even consider incorporating GPL code in the company. What's the problem?

2) benefits from reusing GPL'ed software is more valuable. Conclusion: GPL your stuff as well to gain the benefits and avoid any legal problems. What's the problem?

Otherwise the company is holding on to the belief that they can have and eat the cake, and effectively just wasting their own time.

Re: Twenty questions about the GPL

#72
These questions are interesting with regards to the Goldman Sachs proprietary code that was stolen recently. It seems likely (dare I say inevitable) that some part of GS's infrastructure (just like everybody else's) links GPL'd libraries. When part of the program gets "released" to e.g. an enterprising employee, the FBI, and (possibly) to the general public (as it possibly will), does this force GS to release other code as well?

Re: Twenty questions about the GPL

#73
The real answer is, if someone distributes a Python module in GPL (as opposed to LGPL or other more liberal license), they clearly are either A) stupid/ignorant of the issues surrounding open source licensing, or B) don't want anyone to use their code who isn't also going to go whole-hog down the GPL rabbit hole.

In real life, any useful plugin/loadable lib/module/etc that is intended to be used in a non-academic/research/bits-want-to-be-free-like-speech-and-beer environment is not going to be released exclusively under the GPL.

Re: Twenty questions about the GPL

#74

Earlier quoted context omitted.

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

Yet, oddly, they don't seem to fear the very real consequences of the BSA coming and shutting them down for an "audit".

Re: Twenty questions about the GPL

#75
post #19

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. I don't really like that solution either (it kind of defeats the purpose of having a legally binding license), but it's the current solution silently adopted by a lot of people interoperating with GPLed code using any of the techniques described in your article. In a…

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

"Hope" is not a strategy. Full stop.

Re: Twenty questions about the GPL

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

I think that the GPL is not the problem. Intelectual property is the source of the problem. The GPL is a hack to make the system work in a way it was not thought to work.

Re: Twenty questions about the GPL

#77
post #45
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.

Exactly. If you go down this road, you want big companies to be scared of potential liability. Then you offer to grant them a traditional software license for a traditional sum of money, just like they're used to, and everyone goes home happy.

Re: Twenty questions about the GPL

#79
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…

Using Readline with mzscheme was the first time I, as a user was made aware of the inconvenience of the GPL. It figures, LISP always shows how everything else is flawed.

I'm not sure why that was downvoted.

Re: Twenty questions about the GPL

#80
post #3

[deleted]

The text of the license is smaller than that blog post. And, yes, it contains answers to all the posted questions The author is pointing out that the text is ambiguous. So yes, although it's shorter, it may not indeed contain all the answers. We can argue whether the poster is correct and whether there are ambiguities in the GPL, but your argument doesn't address the question. I don't know the answers to those questi…

At least, not with certainty and credibility.
Post reply on HN