A permissive bubble?

Many years ago, I found an absolutely outstanding archiving program. It was able to compress to about 10% of the original size any type of file – including its own archives.

I understood then nothing of the math behind the data compression. So, my first thought was: “At last, a compression properly done!”. However, doubts started raising their heads. A quick experiment confirmed that after multiple rounds any file would be compressed to 5 bytes size, 4 of these being the archive file identifier. This left 1 byte for the file data. Since 1 byte can have at most 256 different values, it couldn’t encode more than 256 different files. And since the program easily encoded into 1 byte more than 256 different files, something there was wrong.

Checked the files un-archiving. To my amazement, they were restored properly. However, this still did not remove my objections. Something had to be wrong there. I decided to not use the program, despite the peer pressure. And couple of months later proved right: it turned out to be a fake, storing the real data in files that appeared to be a part of the OS. With no compression at all.

I remembered this after reading two articles by Matthew Aslett – “On the continuing decline on the GPL” and “The future of commercial open source business strategies“. The data this research is based on appears to me mostly correct, and I couldn’t find fatal logic flaws in them. However, my logic still couldn’t agree with some of the conclusions, and tended to see other in a different light. Something have to be wrong here.

The data shows that, while both the copyleft-licensed and the permissively licensed projects grow in numbers during the last year and a half, the number of the permissively licensed projects grows far faster that that of the copyleft licenses, especially among the commercial vendors. The analyses concludes that the vendors start realizing that the open source is here to stay, and they start to use business models that include collaborating on an open source product and differentiating on (and profiting from) another stage in the software stack. Driven by the desire to be able to use the open source code without being forced to contribute back their own code, the businesses tend to support open-source projects that are permissively licensed (or to license permissively the projects they open-source).

These conclusions say that the businesses have started valuing the open source, and see it as an important asset and a way to make money. I would be very happy if this could convince me. However, it doesn’t.

1. The data reliability

Somehow I have the feeling that the data might not be analysed properly. I don’t have the resources to make a decent analysis myself, but still, there are some questions to stand:

– Is the data collected properly? For example, some analyses of the installed base of the Linux distributions use data from business sales. According to it, the non-commercial distros have practically no installed base. The reality, of course, is different. It is the method of data collection that provides biased data. This analysis is based on data from Black Duck: it might be useful to have a good analysis on the exact data collection methods employed.

– What about the maturity and the adoption level of the projects being compared? If ten unfinished calculator projects count as ten projects, and LibreOffice or the Linux kernel count as one project, the data (and the conclusions based on it) will be valid only in a specific and rather limited context.

My personal impression (which may be wrong, of course) says that copyleft-licensed projects tend to attract far bigger and more stable community. The result is that the community-driven copyleft-licensed projects tend to be (or to become with the time) more mature and more stable that the permissively licensed projects. There are, of course, exceptions: the maturity of Apache and the stability of OpenBSD are legendary. At the average, however, the vast majority of the big, mature and long-lasting open source projects are copyleft-licensed. So, I think that a data differentiation on the project maturity and adoption level might show that among the successful projects the difference between the growth of the different types of licensing might be smaller, or even close to non-existent.

2. The conclusions

I believe that the “business likes permissive licenses” opinion might be true only when the vendors “attach” to an old, well-established and successful permissively licensed community-supported open source project, and base their commercial software on it.

If the project is supported mostly by a business, it will quickly see the new profit opportunity, and in most cases will like to get it. This will result in either buying the “attached” vendor, or driving it away from this business niche, using their far greater influence over and knowledge about the open-source project. For this reason, attaching to a mostly business-sponsored open source project is a risky idea for a business: very few will dare it (and most will quickly fail). This makes only the community-driven successful projects appropriate as “carriers”, and these are relatively few.

After attaching to such a project, a vendor will generally have no benefit from contributing to it. (Any competitor that uses for free its contributions, while not contributing itself, will have a better investment/result ratio, and thus will be in a better position.) In situations where joint contribution is greatly beneficial (eg. the open source project has strong competitors), businesses may try to get around this Pareto trap by negotiating joint contributions. However, these contributions will be hard to make (if someone refuses to join, they will benefit), and even then always be short-term (a long-term agreement might get Paretoed by an outsider that attaches after the negotiation and refuses to join it). Finally, businesses will start departing from the permissively licensed open source project.

The situation is different, however, if the project is copylefted, esp. under a license of the GPLv3 level. Such a license provides better cooperation while also granting that there will never be egotistic contributors. For this reasons, businesses benefit much more from joining the copyleft licenses.

If the project is supported by a community, it will become overgrown with attached businesses like a ship with clams and crustaceans – and this always slows the ship. In the open source project case, the growing number of freeriders will inevitably disenchant a lot of the project community. The biggest and most successful projects, driven by a huge community, might be able to stand this load for a long time. The smaller, however, might be severely drained or even sunk by the freeriders.

Things are even worse when the vendor decides to open-source under a permissive license a project of theirs, and to focus eg. on its enhanced versions or on commercial middleware that runs over it. With this, they divest a lot of efforts they have paid for, and put them in the hands of every competitor around. If they open the project under a copyleft license, the competitors will have far less opportunities to beat them with their own weapon. (This will still be possible, but typically will be far harder than if the project is permissively licensed. Only in the worst-chance case there is no substantial difference between the two ways of licensing.)

Open-sourcing a project under a copyleft license, when done in a smart way, can also put the competition in a disadvantage. Compiling source from a copylefted project into a closed-source code is usually illegal, except for the licensor – this is their code, they can do with it whatever they like. The competition is more limited in this case. (There is a lot of specifics, but the rule typically stays.)

The copyleft licensing ensures also more community participation. (Some developers don’t care about the licensing of a project. The majority, however, prefer to contribute to copylefted projects due to the smaller opportunity to freeride on their work, and the better chance that code enhancements will be contributed back. The developers who explicitly prefer permissively-licensed projects are relatively few.) Businesses that open-source permissively projects in order to benefit from the community participation, often end up either getting almost no participation, or financing all or almost all of it. If the project is important and unique, it may still attract some developers. However, if a group decides to write a copyleft-licensed clone of it, or to fork the code under a copyleft license (if this is possible), most of the community quickly moves to the copylefted software.

To sum all this: it seems to me that for businesses it is better to participate in copyleft-licensed projects than in permissively licensed ones. (Or to open-source a project under a copyleft license instead of under a permissive one.) Very important, unique an established permissively-licensed projects might be able to be as attractive as a copyleft-licensed ones for a long time, but eventually the copylefted ones prove at average better ROI and smaller risks.

Is it possible that the data and the conclusions of the two articles mentioned above is correct? Completely. However, this will mean that most businesses currently don’t grok the idea and the specifics of the open-source business. With the time passed (and the failures registered), I think that the businesses will inevitably learn the lesson and move towards copylefted projects. And since businesses tend to learn from each other, and to learn rather quickly when the “teachers” achieve a critical mass, the run away from the permissive licenses might be as quick as possible, much like a bursting of an economic bubble.