Is GPL damaging to your ecosystem's health?

In my post earlier this week I sighed about the incompatibilities between GPL and EPL, took the FSF to task for their (in my eyes anyway) disingenuous posture and suggested a way to hack ourselves free of what (I perceive to be) the damage that GPL can cause. But as I was writing that post, I realized that I had things backwards. I talked about what bugs me about the FSF's attitude, and I talked about what I wanted to do about it, but I didn't explain why I cared. It was all about my negative motivation, really. Or perhaps my "negative positive" motivation -- to undermine that which one sees as a threat to getting what one wants. But I didn't talk about my "positive positive" motivation -- what I would actually like to see happen, or my "positive negative" motivation -- why I think there is a problem in the first place.

Eh, ignore all that, I'm beginning to sound like Donald Rumsfield. The point is...there are things I bitch about and that is generally because I want things to be different and I think I can make them so. This attitude happens to be the root of all neurosis, but oh well, here I go again..

What I want is to contribute to software ecosystems that allow the greatest possible resilience, diversity, and adaptation. To create that, one needs to have a large web of interaction. For example, the removal of one node should not cause a cascade of failure across all the dependent nodes -- we need substitutability. (As an aside, the bio-dynamic agriculture movement has a lot of very interesting things to say on these subjects.) To get this, one needs many different paths or edges between nodes. Now, for any ecosystem to work, one needs to exchange meaningful energy. That energy can take many different forms -- it can be food, money, solidarity, status, self-propogation, altruism or anything else that motivates human beings. And in my experience studying complex systems, it is those systems that support multiple forms of exchange that are the healthiest. In a sense (sorry, but I can't help but use the term here) one could say that these systems have a quality of meta-robustness.

What I think is that GPL harms the formation of these ecosystems more than it helps. That's a bold (though not unique) claim, and one that may not be right. But it is what motivated my prior post, and I thought it would be worth walking through some of the logic so that you can judge for yourself.

To examine this, let's look at the {x}PL landscape from the lens of interaction networks. We'll model the various ecosystems and see what pops out. I did this exercise in my head over the last year or so, and thought it was worth sharing. As always, there is no ultimate truth here, only a dynamic interaction or self-adapting and sometimes mutually correcting thoughts. So, it's impossible for my thinking to be "correct", but it is possible that it might be interesting or even helpful in some way to others.

First, let's get an idea of how this approach works, using a simple ecosystem that we are all familiar with. We’ll use the way-back machine and look at the dark days of pre-open source ecosystems. Believe it or not, such purely commercial ecosystems function to this very day.


In the diagram above, we can see a very simple relationship. Company 0 creates software and releases it. It may release an open API, in which case other companies can write to that API freely, with the expectation that customers will purchase both pieces of software, and/or it might license the software to Company 1, which might in turn resell that license to its customers along with its own. Of course, any other company may do the same thing. An extremely important -- and I think under-appreciated -- aspect of this system is that any other company can use the open API and make money off it. In particular, if Company 1 releases a closed library based on Company 0’s open API, Company k can license that closed library without needing to get permission from Company 0. And this is true all down the chain. We end up with an ecosystem that looks like this:



Of course, in this case the web is fed by money only, so it isn't ideal according to my criteria, but it does function pretty well on its own. If we look at the space of the graph, the vertical dimension loosely measures the breadth of functionality (the graphs for the other webs below don’t spread as far in this dimension, but don’t read anything into that, the important thing is that they fade into the distance). The horizontal dimension loosely measures the depth of the dependency chain. Note that this is an extremely important dimension, because it has a strong correlation with reuse and abstraction. In general terms it represents the level of complexity and leverage that independent entities can contribute to the ecosystem.

This purely commercial food web can spread out arbitrarily in either direction, but I propose that there are natural constraints that tend to limit horizontal growth. I’d like to build an Agent-Based Model to more formally test these theories when and if I get the time, but the basic intuition is simply that as we get further and further to the right, the APIs generally get more specialized. That is simply because the markets are always a subset (or intersection in the case of multiple dependencies) of the APIs that a given Company’s product is dependent on. As the market shrinks, the incentive to create software shrinks. This is all entirely consistent with what we see in the real world. There tend to be software creators at the left-most side (Microsoft, Oracle), various relatively large software makers that produce software for those systems (when they aren’t eaten up by their dependency daddies, a very frequent occurrence) to the immediate right (Adobe, WordPerfect, Blizzard), and scattered smaller companies that feed off these ecosystems (Photoshop plugin makers, VARs).

Got that? Now let’s look at another straightforward system. This is a pure open source system. Here we’re looking at GPL because GPL is explicitly designed to foster such a system, but actually you don’t need strong copyleft per se. This model would work as well for any open source system where there isn’t commercial activity.



This is actually even more straightforward, elegant even. Any (compatible!) license can make use of any other license. This gives rise to an Ecosystem that looks like this:



The food web can be quite deep and rich, and indeed we see exactly that in real world GPL ecosystems (Linux, R). GPL based systems can and do grow in both dimensions, creating very beautiful and holistic ecologies. But, we need to ask a question here. Where exactly is the food? We know some of it comes from personal enthusiasm/poor judgement (guilty), some comes from universities, and some comes from corporations with an interest in selling software. But note that in any case the energy exchange isn’t really well aligned to the network structure. We’ll see the implications of that below.

Now is probably a good time to reveal another bias of mine: you need money to produce good software, or at least to produce a significant amount of it in a form that end-users actually want to use. This may be a place where you and I disagree, and if so, fair enough -- you can stop reading, because the rest of my argument won’t be very convincing to you. [Insert smart-ass emacs comment here.]

Next, we come to a much more complex ecosystem, and my personal favorite. This is one that attempts a sort of voluntary shot-gun wedding (yes, there is some contradiction there) between the open source and commercial worlds. Here we’re using the example of EPL, but the license doesn’t have to be weak copyleft -- it could be an even more permissive license like BSD. And (I was going to say “of course” but "of course" it is not that simple) you can mix them all up.



Here, we have companies creating EPL code and at the same time creating code that leverages -- or in some cases is entirely independent of -- that EPL code. We immediately notice something here: there are a lot more arrows! Again, my intuition is that more arrows equals more diversity equals more potential but your intuition might be different. Anyway, if we look at the food web that creates, it looks just as rich, if more colorful, as the GPL web:



But notice that unlike the GPL web there is something more going on here. To the creative and autonomous energy of open source, we add the really practical energy of money. So the thing I love about this ecosystem is that not only can it grow in both directions, it has the energy to do so. Most importantly, unlike the commercial ecosystem it is not limited on the horizontal axis. Why? Because the market size doesn’t shrink as you go to the right. That is because to be commercially viable you don’t need to rely on vendor specific API trees. As the overall ecosystem is not based on or dependent on any particular technology, you can place yourself in the space where you can contribute to and align with any API/functionality subset. And because the backbone of the system is typically the open components (largely because social forces drive it there), if the APIs are too locked into a specific upstream dependency, you can change them!

As above, I argue that this is precisely what we see in real weak-copyleft/commercial ecosystems. Commercial vendors and others (IBM, WindRiver, Google) produce software that other software can interact with via license, API or open source (BIRT, Android SDK, XText, RAP, Blackberry) and these can work with each other. In fact, if I can make be chauvinistic for a second, perhaps this is why the Eclipse ecosystem is leading all sorts of very creative and market friendly initiatives that seem to feed off of one another in all sorts of different and unexpected way (Xtext->iPhone, SWT->RAP). I always know when I’m modeling a complex as opposed to boring system -- I see connections that I didn’t anticipate.

Note something else interesting with my examples above by the way. Technologies that are based around GPL are using EPL tools to create content. So that is a part of the weak and strong interactions that works well. Why shouldn't we try to to extend that success to the software itself?

Warning: now my argument turns critical. I was perhaps unduly harsh on GPL -- or really, the FSF -- in my earlier post, but for the most part, I’m really motivated by the desire to see healthy ecosystems. While I do have an interest in EPL -- I'm an Eclipse Committer after all -- I did not create this analysis to support my point of view. Instead, I came to my point of view based on this analysis. If there are faults in my analysis I agree to alter my point of view.

So then, let’s look at what happens when we mix GPL and commercial licenses. This final diagram is quite a bit more complex but there are really just a couple of key interactions.



Clearly the GPL and Commercial systems can co-exist just as in the prior diagrams, but only to the extent that they are completely separate from one another. And to that extent it isn’t a mixed ecosystem at all but merely two distinct ecosystems.

The EPL cannot exist in either part of this system. It can’t play in the GPL system of course. I’ve got a parochial interest in that issue and let’s just say that that leaves out a great chunk of software, but that really isn’t a problem we can pin on GPL alone. But remarkably, it can’t play in the commercial part of the system either, for reasons I’ll explain below, and we can pin that one on GPL.

So how do the GPL and commercial entities interact? This is the crux, because whenever the GPL is criticized for incompatibility with market incentives, people argue that the two worlds are entirely compatible. As Seweryn Niemiec suggested in response to my last post: “Publish your software on GPL and make money from it too.” True, as far it goes. The idea here is to “dual license” your code. I note with some irony that this stand goes against the spirit of the GPL -- or at least that of the strong strong copyleft adherents -- and in that sense itself represents a kind of self-help IP hack itself. But there is a much deeper, subtler, and far reaching issue here; one that I think deserves contemplation from anyone interested in understanding the complex issues involved. It rests on network dynamics.

Look at the diagram above again. Suppose that Company 1 wants to charge money for a license to their software. In other words, they simply want to play the same game that Company 0 is playing. Seems reasonable, but they can’t do it without obtaining rights from Company 0 and all that goes along with obtaining those rights, i.e. money, lawyers, non-competition, ad infinitum. Why is that? Because GPL terms prevent Company 1 from using the GPL code. So Company 1 needs a license to Company 0's commercial code. Well, can’t Company 1 write their software anyway, and get the user to buy a copy of Company 0's software and a copy of Company 1's software and install them together? According to the GPL license -- or at least the preferred FSF interpretation of it -- no! Here (my apologies for taking so long to get to the point) we find the real damage from the diversity point of view, and the justification for the IP hackery I describe in my post yesterday.

I want to route around that damage because the implications of the above are even deeper than they first appear. The sub-license problem is transitive. Again, looking at the diagram above. Company k does not just have to license from Company 1 -- they must license from Company 0 as well. In fact they must license from every company in their entire chain of dependencies. When multiple companies license each other’s software these relationships become pair-wise! The implication of that is that the marginal increase in software ecosystem leverage and abstraction (the vertical dimension and to my mind software beauty) we can gain with a given input of money (what a teacher of mine refereed to as “green energy”) declines explosively with the number of companies involved. In other words, where L = lawyers and B = given level of abstraction, and N = # entities, L ~= B*N!. [Um.. or probably something like that, I'm too lazy to think it through right now. But trust me, it's big.]

Put even more simply, very few (but > 0) companies are going to want to base their corporate strategy on buying a commercial license to GPL code that they don’t control and that anyone can create a free version of. Very very few people are going to want to make such an arrangement with two partners. And vanishingly small numbers of companies are going to want to do that with more than n partners. We end up with an Ecosystem that looks like this:



What are we left with? Well, the same GPL ecosystem we had before, unless the logic of arguments like this convinces others that a more permissive ecosystem would be a better home. But the commercial situation is actually much worse. Again, now, we can’t even use a dependency’s API without a license! In reality what we would end up with is a separate commercial ecosystem (Microsoft..) and a separate copyleft ecosystem (Gnu..) and a set of separate mixed ecosystems either dominated at the top by small cartels benevolently bending the GPL rules (Linux, Redhat, ??) or controlled by single entities with questionable agendas (MySQL, Oracle).

Which world do you want to live in? Is there a way to live in both? Perhaps self-evolving, decentralized, dynamic software development and deployment systems will convert the distinctions between these various models into not much more than random noise. I’ll return to the diagram from my previous post with an invitation to think about what sorts of software swans might emerge from the networks built by ugly ducklings like OSGi and P2 Aggregator.



Update 11/11 responding to comments: I'll take poster's privilege here and respond to the very stimulating comments below..my responses simply got too long for the comment filter.

I have learned a lot here -- mostly not to make generalizations, even (especially) about a "General" license! So perhaps some cleanup on terms here first..

First Eric, thanks for your kind words. To clarify on the graphs. For each set to try to keep things simple, I'm only drawing the common cases. For instance, in the commercial case Company 0 can license back from Company 1 as well, but I've left that off. Is that what you meant?

After the helpful clarifications from Simon and Laurent, perhaps we can simplify things along a couple of dimensions.

1. 1. I am referring to the "hard" GPL only. A couple of people brought up LGPL in the context of an overall GPL based ecosystem. To be clear I am referring to the GPL sans linking exception and I think that conflating GPL with the LGPL or GPL + L is literally semantics in the sense that while there is a cultural and labeling linkage between the various flavors the implications of each are completely different. LGPL and EPL are even somewhat compatible. To that extent, they don't make an ecosystem per se but only per definition/branding. So for LGPL or GPL + linking you could just use the same graph as for Commercial + Weak-Copy left system. There is the added benefit that you can mix the strong and weak copy-left components more easily so perhaps there should be a fifth set of graphs in there. That's very interesting politically, but let's leave that aside for now. I'll just say that I love Simon's comment "In fact all would be easier if the EPL had been the LGPL". How true that is!
   
   But the main point is that to the extent a developer chooses to use pure, unadulterated GPL, the last scenario applies. I note that in practice this is how we really think of it -- as separate beasties. If someone says "we use LGPL" then people thinking about commercializing will say "OK, that's kind of a pain in the ass, but we can probably live with it".



2. I am concerned with the non-ideological authors only. By this I mean, to use a very loaded term, the "exploitive" GPL users who use GPL to meet their own business goals in a protective way -- not because they want software to be free but because they want to charge for it. And so my argument as it were is with sub-groups of the two groups that Simon mentions: [groups] who ..accept to sell a "proprietary" version and those who prevent competitors from dual licensing stuff based on their software to clients who did not buy their proprietary license first. Now, I submit that there are a lot of companies and organizations that meet this definition.
   
   I appreciate Simon's comment that "But everyone knows these players, and no one trusts them to build software that we want to dual-license later on" and it sounds like the honest brokers make middle-ware exceptions and so on. I don't have enough experience with GPL licensing world to know how well that works, and it is gratifying to hear it. But still, there seem to be a lot of machinations there and various combinations and I imagine it can be a bit of a minefield. I can't help but think that it would be simpler if people just settled on weak copy-left for the majority of cases, perhaps keeping some of the real crown jewels aside.
   
   There is of course much gray in this area. The most annoying and unexpected and all too common in my experience are with University sponsored projects. I imagine a typical scenario is that somewhere along the way someone tried to convince the University administration to go open source and in order to make that argument they say "if we use GPL, we can always make money licensing it commercially to corporations". Of course, in most cases that never really happens but the damage (from my perspective :) ) is done. On reflection, it I guess that means that it is ironically the gray area that I'm concerned about. Those companies and institutions that have good intentions but that have a bit more of an "I'm hungry now!" attitude or more ideological resonance with strong GPL. These are generally the places that are making really cool pieces of code that would be really useful to a lot of people, and that a lot of people use, but that then can't be integrated with the rest of the commercially oriented eco-system. This is where I think there is a tremendous amount of potential lost and I'd like to find ways to make those worlds work or grow together better.



3. I am not making an argument against the ideology of GPL, but against it's suitability as an ecosystem and the corresponding "have your cake and eat it too mentality". So, my answer to the rhetorical question of the title is "yes". :) I really do have affection, ambivalent affection, for the pure GPL approach as an exercise in economic and cultural hacking. Are we all seeing the same thing then when as Laurent says, "[GPL has] goals that are beyond 'building a healthy ecosystem'" and Simon says "dependency graphs miss because the GPL is not as much about developing a thriving ecosystem as about guaranteeing freedom in the long run."?
   
   That's fair, and I just want people to see that. I'm just arguing that GPL + commercial is not as healthy weak copy-left + commercial or that they are even close, at least in the short to medium term. In other-words, my argument is aimed at those companies or individuals who want to make money off of their software that they should choose weak copy-left over GPL. Maybe it's obvious that strong GPL and commercial software don't really mix as well as some people claim and all of these graphs are just making an obvious point more complicated than it needs to be! People who are making the decision to participate in GPL should see it as a long-term investment in freedom and that isn't compatible with how it is being used in many cases. Perhaps it is dual-licensing itself that should be prohibited under GPL! And yes, I realize that that would be a hard thing to accomplish legally.

Let's see, this response is way too long already. I think most of Simon's arguments re: Java are spot on. But again here I'd say that the reason GPL worked is not because of its own goals or ideology but because its ideology happens to match up well to narrow corporate interests. Strange bedfellows..

Why have you not covered the possibility to dual license under GPL *and* EPL? This scenario is the proper way to incorporation of GPL content in the ecosystem you are describing.

To Laurent's question "Why have you not covered the possibility to dual license under GPL *and* EPL? This scenario is the proper way to incorporation of GPL content in the ecosystem you are describing." Yes, that is what I would like everyone to do. :) But note that the people who are in the categories I describe in (2) will not do that, because doing so get's rid of all of the perceived advantages. In other words you can lump that into the weak copyleft + commercial category because that is where it goes. By the way for anyone who wants a GPL license for my EPL code, let me know and I'll be happy to grant it! I'll give you a commercial license too if you feel like paying me for it.

Now I'd like to ask for some advice from the GPL experts, since I think people have said in response to this and the previous post that my hack isn't really at all a hack. Actually, I don't think so either, I just meant it in the most general sense of a useful but somewhat ugly way around a particular engineering issue in a way that might not have been contemplated by the original authors. Does that mean that it would be perfectly ok to use GPL code in the way I describe, without even using the P2 aggregator bit? If one simply created a generic API, wrote a plugin for GPL code -- of course while providing all of the code for that plugin under GPL -- and then simply bundled that plugin and it's GPL code with the software itself that that would be ok?