More Nerds Argue
Remember those Nerd Lawyers arguing over the GPL and plugins? Now there are some Nerd Professors arguing over the same thing.
This blog is interesting because it contains a host of opinions, all well-stated. If I understand the consensus (such as it is), the answer to writing non-GPL plugins to a GPL program is to write a GPL plugin that provides an interface that a non-GPL program can talk directly to.
Here’s the bit of commentary from the FogCreek developers that supports that interpretation:
In Kiln, to avoid running afoul of the GPL, while still making a viable commercial product, what we did was to design the product so that the closed-source browsing/repository management/code review component was kept entirely separate from the open-source code storage component.
This aligns with some of the arguments in the Nerd Lawyer discussion – one which I originally did not agree with, but am coming to accept.
I say “coming to accept” because I am of the opinion that plugins may not necessarily be GPL, if the original work provides a “clean” interface for plugins. So, it bugs me when the argument is that plugins “are very probably derived works as they are potentially (and generally) significantly more intimate with [the original work's] internals”, because that makes me think the plug-in interface is not “clean”.
A minor point
Such discussion is good, but the good professor goes a bit far I think here:
George Orwell argued that the real purpose of censorship is to make people worry about what writing something troublesome might cost them, so that they never actually write anything that would have to be censored. Every time someone puts the GPL on something, they are forcing other developers to make the same kind of decision: accept someone else’s idea of what “free” means, or run the risk of not being able to use their “free” software without a whole lot of trouble.
Of course, the truth is any time someone puts any license on something, they are forcing other developers to make a decision: accept someone else’s terms, or run the risk of not being able to use their software. In this area, there is little difference between the GPL and any other license. Why Orwellian overtones need to be introduced escapes me.
I’ve often noticed that people tend to really dislike the GPL when they want to use GPL code, but don’t want to accept GPL terms.
If you want more
This seems as good a place as any to note a somewhat similar discussion on WordPress themes / extensions / plugins.
#1 by Jason on April 13, 2010 - 11:11 am
Greg,
Thank you for the comments!
On point 2: See saulgoode's comment here, but this the crux of (one of) the legal argument for derived works.
My counter-point (with no legal cite) is the example of an GPL-licensed OS. It provides a "clean" API for applications to run on. Yet no one (that I am aware of) has made the argument that all programs running on Linux must in turn be GPL.
That is why I am currently of the opinion that the "clean-ness" of the interface is what matters. If the original work provides a "clean" API / interface then the work is less likely to be considered derivative in my mind.
This also helps explain why answers differ and is in line (I think) with Mr. Van Lindberg's analysis. (Assuming I understand his analysis, I tend to agree with his argument).
On point 3: The funny point to me is that people want to benefit from the mores that created the code without following them in turn. It's understandable, just amusing.
#2 by Greg Wilson on April 13, 2010 - 10:30 am
Thanks for the link back, but a few comments:
1. There's only one professor in the argument, and I'm not very nerdy any more
2. You say, "I am of the opinion that plugins may not necessarily be GPL, if the original work provides a 'clean' interface for plugins." Can you cite statute or precedent to back up that opinion? That's what will matter if this ever comes to court; the fact that Van Lindberg and Fog Creek's lawyer disagree is a sign that no one actually knows which way the chips will fall.
3. You say, "…people tend to really dislike the GPL when they want to use GPL code, but don’t want to accept GPL terms." That's tautologous, isn't it? If I was OK with the GPL's terms, then I wouldn't dislike the GPL…
#3 by powered_by_tux on April 13, 2010 - 7:02 pm
Wow, so the GPL is now put on the same level as censorship. Now, that is something new. You must hate proprietary software way more than the GPL then.
Do developers not have the choice under which license they put their work anymore?
#4 by saulgoode on April 13, 2010 - 4:31 pm
It is notable that the license for the Linux kernel contains the following proclamation in addition to the GPL licensing:
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".
Eben Moglen has expressed more than once that Linux is not "pure GPL" and though I have never seen an elaboration on this comment, it seems that his conclusion is based upon the above addendum (to my knowledge, Linux licensing contains no other variances from "pure GPL"). While the wording of the addendum presents itself as a "clarification" of the license, it is more accurate to consider it an "exception" to the GPL.
Regardless how one would characterize the above license addendum, it serves the purpose of making usage of "normal system calls" to the Linux kernel a non-issue with regard to licensing. However, it should not be presumed that courts would look to Linus Torvalds' choices as to what constitutes "derived works", or "normal system calls", when deciding the reach of the GPL when deciding other cases. Another developer might consider all interfaces to his code to be "non-normal" and fall under the GPL's linking terms. And this is where things get interesting.
When a programmer holds his copyrighted codebase as a trade secret (i.e., closed-source software) but then publishes details for an interface to that codebase, it has traditionally been reasonable to presume that the published API provides for the equivalent of "normal system calls" and can acceptably be employed without the interfacing program becoming a derived work[1]. But this approach fails in the case of open source software, where the entire codebase is effectively published, including any and all "APIs". Just because an API is published — even if it is done in a flexible manner intended to encourage "plug-ins" — one should not presume that it is necessarily a "clean interface" or that accessing it doesn't constitute a derived work (just because "Harry Potter" is published doesn't mean it is fair game for producing derivations).
[1] This presumption is not necessarily true though (even for closed-source software), as seen in cases of Software Development Kits (SDKs) being provided for closed-source software which bear their own, separate licensing from that of the main codebase.
#5 by Jason on April 13, 2010 - 10:04 pm
saul,
Thank you for the comments!
This is an area of the GPL that I wish I had a more complete understanding of – complicated by the fact that the legal interpretation may differ from the developer's intention.
Part of the problem here is (I think) copyright isn't such a great match for software.
Also, I am troubled when two honest parties are unable to agree on the meaning and scope of the license. That is, I fully expect corporations to play legal trickeries and look for loopholes (a la Novell), but I don't expect two developers to have to worry if they are in compliance or not.
That's not to say that I expect all developers to agree on the merits of a license, but I would like everyone to be able to agree on what it means and how to comply with it.
I wonder what the ratio of confusion over the GPL is when broken down something like:
"legal gobbledygook" : "loophole hunting" : "complex concept"
#6 by saulgoode on May 9, 2010 - 2:53 pm
While roaming the Web, I encountered
this whitepaper (PDF) which provides some additional perspective on the legalities of this issue.
Though I don’t totally agree with the ultimate conclusions of the authors with regard to Linux kernel modules (they don’t seem to place much stock in the “normal system calls” exception of the kernel’s licensing or the developers’ GPL_ONLY flagging mechanism), I do agree with their general assessment of derivative works in software and the applicability of copyright to header files.