Can The Dynamic Duo Free Software from the GPL?

Disclaimer: Hey I'm not a lawyer, ok? Get your own damn legal advice. In fact, if anything I say makes sense to you, then I wish you'd explain it to me, because it sure doesn't make any sense to me.

Updated 11/10: To understand my motivation for this post, you might want to read my next post, which explains why I think GPL is not the best choice for building healthy software ecosystems.

Updated 11/9: I got some feedback on this blog which -- fairly I think -- took me to task for being too harsh on GPL and FSF. My intention was to express some frustration, poke a little fun at some sacred cows, and offer a creative alternative to the dilemma that so many of us face all of the time when we have to choose between more permissive flavors of software licenses like BSD and EPL, and the much more restrictive GPL license.

I thought I was clear about this, but if there is any confusion, I am not attacking people who make the choice to use GPL. I've considered using the GPL for projects in the past, and I might again in the future. For what it's worth, while I would like to use the software I mentioned below -- and dozens of others -- I'm just fine with the fact that I can't. And I'm embarrassed contemplating the image I may have created of "ranting" against the injustice of the GPL license and laying awake at night plotting ways around it. After all, in the end, I can simply recreate that functionality. The next iteration is always able to learn and grow from the last, and providing software under a license that others can use freely will always give such software a leg up. Anyway, let me assure everyone that personally this really isn't a life and death issue.

But on the other hand, as a software developer, from an almost aesthetic point of view, there is nothing that frustrates me more than seeing the wasted energy spent on having people work on the same functionality for multiple projects under multiple licenses and organizations, when those people could be working together and getting much more accomplished with higher quality. (Yes, I do see the benefit of competition and diversity, and I think there is a value in that, but ultimately the gains from that are overwhelmed by the losses to cooperation.)

The central point of my IP engineering straw-man was to get people to think about alternatives. While I don't see anything wrong with people choosing a particular license, I don't see anything wrong with creative engineering around that license either. We do it all the time. Why should people have to go to the extreme of re-writing things so that everything goes through a socket when there might be better alternatives just to satisfy an attempt by GPL to plug holes that are ultimately un-pluggable? My view is that the terms of the GPL just aren't aligned with the distributed, dynamic way that people are doing software now, and this contradiction is going to only become more apparent over time. If I can help that process along, I'm proud to.

And I did intend to prod FSF a bit, because frankly I think they could use the prodding. There isn't something fundamentally bad with their approach. As I say below, I think there is a lot to admire about copy-left -- it's a daring, ambitious, creative and fascinating response to a lot of issues in our society that go far beyond software licensing. But as in most cases, ambition married to dogmatism leads in the end to contradiction and ends up requiring reliance on half-truths and the expression of naked coercion to support itself. And so yes, I do think that the claims on the FSF website are absurd, disingenuous and actually harmful to the ultimate aim of the FSF, if that aim is education and not indoctrination.

But no, I didn't mean to do it in a nasty way. My standard is to not say something online that I wouldn't be willing to say to someone's face. In an imaginary barstool conversation with someone from the FSF I'm afraid to say that I could imagine myself saying "you know on your website, the part where you say... that's total bullshit, isn't it?" I have had those kind of conversations in a friendly way in many contexts -- and taken as good as I gave -- but perhaps that's the kind of conversation that requires a few beers to go along with it. Anyway, I'm leaving the original post as is, because I don't want to alter history, but with an offer of free beer to my GPL friends when I see you non-virtually.

Recently I wanted to use some really nifty software within my own projects. I'm not going to name the particular project here just because a) it isn't relevant to the argument, b) my concern is not restricted to any one project, and c) I'm also an independent software developer, and respect the struggle that other small companies have trying to find the right strategy. The important point is that there is great potential for collaboration with said software but it uses GPL, which means I can't use it because the the two licenses are fundamentally incompatible.

The software also happens to be based on EPL code -- which I guess makes it technically incompatible with itself! I can't help but say that this approach seems unfair to me. Basically, one is taking the attitude that "I'll use other developer's software under their more open terms, but then release my software under terms that prevent those developers from doing the same". That's fine for commercial software, but in my opinion not so good for "open" software as it makes the relationship one-way. That's a subject I hope to return to in a later post, but ultimately, the banker's question has to be "why participate in a collaboration where the GPL entity is the only company able to make money off of the collaboration?"

As I researched the whole issue and went to others for ideas and advice, I headed over to the GPL site, and found myself looking at pitch perfect double-speak:

So now, let's see... If I want to use GPL Software X, and I decide to include that in my EPL or commercial release, then the Free Software Foundation will use the full power of the courts to prevent me from doing so. I can't buy anyone a beer and I can't even write what I want to. What sort of "freedom" was that again? In what sense exactly am I not "restricted"? I think what the page is really trying to say is "Freedom is Restriction". Hey, I understand and am (ambivalently) admiring of the whole idea of GPL, but could we drop the hypocrisy and variations on a theme by Orwell? Please?

Anyway, I guess I'm not going to get what I "deserve" out of the GPL, so is there a way to liberate it instead? After thinking about it for some time it dawned on me that there were some tools in the Eclipse jail-breaking kit that just might fit the bill.

The first thing we need to understand is what won't work. I can't have a direct dependency on the GPL code, obviously. I can't build something that requires the copyrighted GPL software to compile, and I obviously can't deliver it either.

But, what if I encapsulated the functionality that I wanted into an independently developed set of APIs? Then, I could create a separate code base for a plugin that implements that generic API and delegates the calls to the target GPL API. (Note that I can release the same or other software under various licenses. For example, I could make my Generic API available under EPL and/or BSD.) BAM!!

Perhaps we can escape this diabolic trap after all. We can see in the following diagram that we've zig-zagged around any dependency issues. The OSGi plugin loads the GPL functionality at runtime, not design or compile time. Take that, fiendish enslavers of software! SOCK!!

But there is still a problem here. Though no commercial software vendor would ever claim such a right and get away with it, the FSF actually wants to intrude on what software a program is allowed to link to dynamically. For some reason I can't fully articulate, as a lover of software the idea that someone could prevent you from executing something from within a program after the software is written -- even though you have the rights to use both pieces of software independently -- seems absurd to me, and even a bit wicked.

Now, as far as I know, the FSF has never had any success convincing a court of the enforceability of this unique approach to deconstructing copyright. It essentially requires a form of copyright protection that can see into the future and read minds. ("I just know that he wrote that software with the intention of allowing other people to link it to my software.") But in any case, the only hope of actually enforcing this lunacy rests on software delivery, not development. That's because each software component isn't at all related until the whole distribution is assembled, packaged and provisioned.

That is an extremely important point, because it means that as say an EPL developer, I would be free to use the above strategy without putting myself or my software under any jeopardy at all. (Now would be a good time to scroll back up to the top and read that disclaimer again..) I could even put that software on a server somewhere and let people build it themselves. (OK, Richard Stallman might have something to say about that, but in that case just put your hands over your ears and repeat "nanananan..I'm not listening...I'm not listening..." Or maybe a freeze ray would be in order.) The only trouble -- again, under the most ludicrous potential court ruling, but it isn't like ludicrous rulings never happen -- would be when I actually tried to deliver software to someone. If I bundled said GPL software with my project or product, and I hosted that bundle on my site, I maybe sort of possibly could be violating the GPL license. Somehow.

So you may have been wondering how P2 Aggregator fits into the picture. Here's how: nobody ever actually delivers the software at all! Instead, the end user selects the components that he or she wants from an aggregator site. If you think about it, aggregator is really a dynamic plugin mechanism, but for deployment rather than run-time. And, like plugins, it allows us to insert indirection into the dependency chain. You can assemble stacks of dependencies in any arbitrary way as long as those dependencies are satisfied. So, let's use dynamic deployment in the same spirit we used dynamic development. POW!!

Dependencies are ultimately specified in a file somewhere but in such a way that the software as delivered meets the appropriate license for the appropriate usage path. In other words, the GPL site "conveys" the GPL content, including as appropriate the dual-licensed proxy-API and plugin code. The EPL licensed project provides all of its code and thus of course avoids any potential issues of license incompatibility. And the DMZ site provides the generic API (and optionally the proxy plugins) under BSD license, which is compatible with both. WHAP!!!

The really subversive part is that a commercial vendor might even be able to use this method to deliver software using GPL functionality. KA-POW!!!!

Note that the P2 aggregate approach is very different from the kind of "aggregate" discussed in the GPL FAQ. In a typical aggregate like a Linux DVD Distro (does anyone actually make those anymore?), all of the software is put in one place. Instead, with a P2 Aggregator provisioned application, the customer assembles the software for his or herself, just as he or she does when downloading applications from the web. The GPL EPL software dependencies never exist anywhere else! So there is simply no sense in which the two sets of software could be said to incorporate each other.

As a thought experiment, imagine a customer who wants to use a mixture of open source and commercial software to edit photos. If she installs PhotoShop and a GPL'd Photoshop plugin, she couldn't be accused of violating copyright, could she? What if she went to an independent website and that website had a link for downloading Photoshop and another one for downloading the GPL plugin? Would that website be violating the GPL copyright? What if that website were instead hosted by Photoshop. Would that magically cause Adobe to be in violation of copyright? Now, imagine that both Photoshop and the plugin were hosted at oh, say the Mac App Store? Would the App Store be in violation? What if instead that user went to an Eclipse Market provider and selected a commercially licensed Eclipse image editor, together with a GPL-based plugin, which were then installed together? As far as I can see, the distinctions all quickly reduce into absurdity.

I'd love to hear your point of view whatever it is. To avoid wasting a lot of time, I'd especially like to hear from you if you think my idea won't work! (And in the interests of giving the Eclipse Foundation legal team a sound night's sleep, no, I am definitely not planning to test this theory out on an Eclipse hosted project.)

Well, kids, can Captain Aggregator and The Plugin free captive software from Dr. GPL? Or is our attempt to free ourselves from the forces of [...hmm... "forces of people with a different point of view" doesn't really have much of a ring to it, does it] doomed to failure? Quite a cliff-hanger, eh?