
Twenty questions about the GPL - twampss
http://jacobian.org/writing/gpl-questions/
======
blasdel
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's _too fucking complicated_ to
deal with in real-world situations.

~~~
jacobian
Yeah, that's really the nut of the problem, isn't it. Short of finding a
lawyer qualified to speak to these issues -- which I can't afford -- my only
other option is to simply avoid the GPL. Which sucks.

~~~
mquander
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 world where technology advances an order of magnitude faster than legal
theory, it's just going to be a fact of life for a long time that there are
many technological questions that have no clearcut legal answers.

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

~~~
callahad
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
infractions / events, and try to humanize the free software community. In most
cases, there isn't a litigious company lurking in the shadows, and a show of
good faith will go a long way. It's also quite useful to direct attention to
high profile products that are safely using and modifying GPL'd code, like the
Kindle.

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

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

------
flatline
Nice list of questions...I've used GPL'd software extensively, read numerous
discussions about the license, and read the GPL several times through, and am
still uncertain (or at least uncomfortable) about the answer to most of these
questions.

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

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

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

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

------
theBobMcCormick
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 so high on the HN front page.

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

~~~
benatkin
No, he's being downmodded for suggesting that the author should have to
contact one particular organization to get answers to simple questions about
something as widely used and discussed as the GPL.

~~~
tjr
Then he's being downmodded unjustly, as he listed two specific organizations,
included an "etc." in his list of organizations, and prefaced the entire list
with a "perhaps".

Regardless of where the answers to these questions come from, it would be good
to share the confusion with the FSF, in hopes that they can remedy it. I do
not believe their goal is to inflict confusing licenses upon the general
public, but they do have rather specific goals and attempt to address those
goals in their licenses.

~~~
benatkin
Well, there's no such thing as the GNU Foundation (there's the Free Software
Foundation and the GNU Project), so technically there's only one. :)

Assuming that he meant Free Software Foundation, his mention of The Free
Software Law Center invalidates my point, though, because clearly they're not
closely tied to the Free Software Foundation. Otherwise, they wouldn't say
"Open Source" on their home page without going into a diatribe about the term.

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

~~~
Semiapies
The GPL is ultimately about ideology, not software. Note all the comments by
GPL-boosters demanding to know what kind of unsavory license-bending the
poster _really_ wants to engage in due to his asking a few simple questions
with a distressing lack of clear answers.

------
callahad
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 change the answer to #1; you still depend on
it, thus your work still counts as a derivative.

3\. Not depending on foo.py, but using it if available does not change the
answer to #1. Once your code makes use of the GPL'd library, it must also be
GPL'd.

4\. Yes, calling GPL'd libfoo.so via Ruby/DL requires that your code be GPL'd;
the full GPL does not have library exceptions like the LGPL.

5\. Separate distribution does not change the above.

6\. GPL'd foo.js and proprietary bar.js can be combined into a single
foobar.js and retain their respective licenses, so long as they are
functionally independent. "Inclusion of a covered work in an aggregate does
not cause this License to apply to the other parts of the aggregate." (Last
line of Section 5 of GPLv3)

7\. I'm not sure of the specifics of XUL, but I'd imagine depending on a GPL'd
.js file and including that in the XUL app would indeed create a derivative
work, and require the XUL app to be GPL'd.

8\. Sharing modified versions between internal teams does not count as
conveyance, so long as those teams are within the same business entity. See
[http://www.fsf.org/licensing/licenses/gpl-
faq.html#InternalD...](http://www.fsf.org/licensing/licenses/gpl-
faq.html#InternalDistribution)

9\. Unsure, but I'm learning towards distribution to a fully-owned subsidiary
still counting as conveyance to an outside entity, and thus triggering the
GPL. If they're different entities to the IRS, they're probably different
entities to the FSF.

10\. Conveyance to a majority-owned subsidiary seems like conveyance to an
outside entity, and would thus trigger the GPL.

11\. Price isn't a factor; the applicability of the GPL is wholly determined
by the distribution counting (or not counting) as "conveyance" to an outside
party.

12\. As per the FSF's FAQ, conveying the work to a contractor for use off site
_does_ trigger the GPL.

13\. The mechanism matters. If Jane uses the software off-site or is able to
make or receive copies, then it would trigger the GPL.

14\. Giving the modified Foo.exe to consultants does trigger the GPL, as per
the FSF FAQ above.

15\. Using a company-owned terminal with company-modified GPL app does not
count as conveyance, and does not trigger the GPL.

16\. Allowing outside parties to download the modified Foo.exe, even though
they are on-site, does trigger the GPL; consider it akin to purchasing
software from a brick and mortar point of distribution. Where you received it
doesn't matter, it's the fact that you can take it home.

17\. The Job Applicant is not yet an employee of Initech; if they receive the
modified Foo.exe, it's been conveyed to an outside entity, and thus triggers
the GPL. The means of conveyance are not important.

18\. Making the modified Foo.exe freely available on a public web server
clearly triggers the GPL's conveyance clause.

19\. Password protecting the download of Foo.exe does not matter if an outside
entity can legitimately receive it; it's still conveyance.

20\. My shot at a basic principle for laypeople: "If you can walk away with
the application in any form, it is conveyance."

Bonus: Jacob shouldn't have these problems since he's a Django developer;
"Mere interaction with a user through a computer network, with no transfer of
a copy, if not conveying." Make the Django site live in a well defined place,
and make all the interaction happen in the browser. Congratulations, you've
used the software-as-a-service loophole.

~~~
vinutheraj
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 !

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

~~~
wmf
I'm not sure why this was voted down; here's the relevant text:

NOTE! This copyright does _not_ cover user programs that use kernel services
by normal system calls - this is merely considered normal use of the kernel,
and does _not_ fall under the heading of "derived work".

[http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.3...](http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=blob;f=COPYING;h=ca442d313d86dc67e0a2e5d584b465bd382cbf5c;hb=HEAD)

~~~
blasdel
I voted it down because it was so ming-bogglingly stupid that I yelled and
spun around in my chair! I briefly considered unsubscribing from your blog
before I calmed down.

The note in COPYING is just to allay FUD, it's not actually necessary and
certainly isn't a GPL exception.

For starters, nearly all programs (by volume) making syscalls don't use any
specific to Linux -- there's no way it's derivative if it runs fine on another
kernel. Furthermore, responding to syscalls is what Linux is FOR in _'normal
use'_ \-- not even the FSF is jackass enough to claim that bash scripts are
derivative works, even if they are riddled with bash-isms.

------
caffeine
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?

------
asciilifeform
I am still waiting for an example of _anyone_ who:

A) has anything at all to fear from the GPL, and

B) isn't a (would-be) parasite. See this as an example:
<http://news.ycombinator.org/item?id=610764>

