The gridlock economy and software licensing

Michael Heller wrote a book entitled The Gridlock Economy: How Too Much Ownership Wrecks Markets, Stops Innovation and Costs Lives. Gridlock is a general economic concept describing what happens when there are so many owners of units of private property, it becomes infeasible to negotiate with all the owners necessary to assemble them into a new work. In one example, a drug company was unable to bring a drug to market because a long list of patents had to be secured to begin required testing, and the cost of doing so was prohibitive. Gridlock leads to resource underutilization and decreased innovation.

The original BSD license is another example of gridlock: the license included a seemingly innocuous term requiring any advertisement for a product incorporating the code to credit the original authors. This sounds innocuous until you assemble a multitude of BSD license modules, and realize that there's no longer room on your advertisements for anything else. The result is that companies avoided using any BSD-licensed code. This was repaired in the modified BSD license used today.

Software today is in a similar gridlock: there is an immense body of code out in the world, but it is impossible to legally combine code released under incompatible licenses, and even where licenses are compatible, it rapidly becomes infeasible to keep up with an increasingly long and complex list of requirements. When you build a product out of two or three large open-source systems, this isn't a problem; when you build it out of 200 small open-source modules, each by a separate author, you end up deciding you really ought to have written it yourself. This pushes more and more code into the proprietary space that has long since been written before and should have only been written once.

Public domain open-source movements like Kompimi aim to reverse this trend by pushing more license-free code into the ecosystem. With no ownership, nothing limits free assembly and synergy of an unlimited number of modules by many authors, leading to more sophisticated software - and more reliable software, since the effort spent on generating many versions of a module can be concentrated on creating one high-quality module and getting it right. This leads in the end to more wealth for everyone.

All content in this document is granted into the public domain. Where this is not legally possible, the copyright owner releases all rights. This notice may be modified or removed.

Kompimi C Data Structure Library: Dynamic Arrays

Although it's been slow going, the first Kompimi component is in development - the Kompimi C Data Structure Library. Its Sourceforge page is here:

http://sourceforge.net/projects/kompimi-cdsl/

So far I've implemented dynamic arrays, also known as vectors in C++, a vector permitting insertions and deletions that automatically grows to accomodate new elements. The interface was designed to include all the functionality of C++ vectors. The interface still needs some better documentation, and I need to adopt a consistent doc format that can be used to generate pretty interface web pages.

This container is very generally useful, and also surprisingly subtle in its implementation - ensuring that a sequence of insert/remove operations at the end of the array takes amortized constant time requires not only geometric expansion, but also requires that the expansion and unexpansion ratios be chosen in a way that prevents continual reallocation in an insert/remove/insert/remove/... sequence.

More concepts in the design document here:

http://sourceforge.net/docman/display_doc.php?docid=114694&group_id=231603

Preliminary unit tests are included. When this interface is thoroughly documented, next comes the next most important data structure: the list. I plan to implement this with unrolled linked lists to make it efficient.

All content in this document is granted into the public domain. Where this is not legally possible, the copyright owner releases all rights. This notice may be modified or removed.