Reflections on the 9th Annual Open Source Think Tank

I recently attended the 9th Annual Open Source Think Tank.  This was OSEHRA’s third year of participation, and it has been quite interesting to watch continued growth of the open source community across so many business areas.  
A new Community Leadership track provided lessons on community management planning and strategy, highlighting the differences between horizontal and vertical communities.  This year’s case study featured the emerging Internet of Things (IoT) and open source’s potential role in fostering an inclusive ecosystem across a couple of  health IT business ideas.
One of the trends that hit home is that with the growth of code under licensing, the larger corporations are increasingly beginning to understand the merits of permissive licensing, and the potential dangers of mixed licenses. This discussion validated our decision to accept only code certified under Apache 2.0.
One other positive note was that OSEHRA is becoming widely known within the open source community, and is being watched closely as a model for open source projects in vertical markets.  I’m proud of our growing, vibrant community.   
There were some discussions on the observation of IRS’s scrutiny granting tax-exempt status for open source foundation applications. Some have suggested that working with existing non-profits for new open source activities might be more cost effective and time efficient. 
A handful of OSEHRA community members attended the Think Thank and I would like to hear your impressions. The Think Tank is a great place to benchmark our community with other peer communities. I came away reaffirmed the OSEHRA community has done well and is poised to successfully address the challenges ahead.  
Please plan to join us at the Summit 2014 on September 3-5, where you’ll get insight into future initiatives from both OSEHRA and the Department of Veterans Affairs.  You can register now here.  We’ve also got some exciting announcements coming up, so stay tuned!
Seong K. Mun, Ph.D.
President and CEO


Source code access protects users - lack thereof endangers them

K.S. Bhaskar's picture

I respectfully beg to differ on permissive licenses vs. copyleft licenses, and the recent OpenSSL Heartbleed offers a valuable lesson on the value of copyleft licenses.

OpenSSL has a permissive license with no copyleft (  This means that it is possibleto incorporate vulnerable versions of OpenSSL in products with proprietary licenses and not publish source code, or indeed to make any sort of disclosure.  So for any vendor who chooses not to make a statement or disclose source code that can be audited (server and client applications distributed in binary form, routers, Wifi access points, etc.), a permissive license is just like proprietary software - it allows the vendor to not disclose their code, and it fails to protect users who have no way to know whether they are vulnerable.

I have long been a fan of licenses with a strong copyleft for exactly this reason. on the fallout from Heartbleed for software on clients is worth a read.  If a vendor does not disclose that they have bundled a vulnerable release of OpenSSL with their application, and does not patch their application, users are at risk and don't even know it.

We will be living with the fallout from Heartbleed for years to come because of OpenSSL's permissive license.


Relevant article regarding permissive vs. copyleft licensing

Maury Pepper's picture

Here is a short article in Dr. Dobb's, "The Conflict at the Heart of Open Source" ...



Culture eats Licensing for Breakfast

Luis Ibanez's picture

                             “Culture Eats Strategy For Breakfast

is a remark attributed to Peter Drucker and popularized in 2006 by Mark Fields, president of Ford Motor Company.


Let me rephrase it in this conversation as:

                             "Culture Eats Licensing for Breakfast"

The "strategy" of forcing collaboration by imposing copyleft licenses, is a well-intentioned, but inneffective approach.


The premise of reciprocal licenses, is that:

  • because the reciprocal (copyleft) license includes terms requiring the resharing of modifications (improvements) made to the software.
  • then, participants in the community will indeed share such modifications and
  • the modifications will be integrated into the common pool of resources (the software / documentation / tests), and
  • the modifications will then be re-deployed to all recepients who want them. 

There are two flaws in this approach:

The first one, is the presumption of Software as a finished product, what Eric Raymond referred to as "The Manufacturing Delusion", the confusion that lead many to believe that software is a product, when in reality software is a "service delivery platform". That is, software is not akin to an appliance, but akin to the Power Grid, or the Highway System. These reasonsing of finished product lead to understimate (or plain ignore) the high cost of integration, re-deployment and re-training that a modification may trigger in a service delivery platform. The Heartbleed bug is actually a clear illustration of that cost of integration, redeployment and retraining.  The problem in Heartbleed was not that someone was not sharing the code. On the contrary, that's how the bug was introduced: by a kind contributor who submitted code for integration. The problem in Heartbleed is that the OpenSSL project lacked the "Thousand Eyes" that should have throughly inspected the new code contribution, detected its defects and fix them before it got integrated in the code.

The second flaw, in the licensing approach, is the presumption that the rule will trigger willful compliance and effective cooperation. It is reasonable, it is aligned with the legal framework of copyright, but it is useless in practice. Since the participants in communities simply resist coercion (such is the human nature, and with good reason). It is then easy to satisfy the letter of the reciprocal licenses, without satisfying their spirit. For example, one can easily share all code modifications to a software platform in an barely readable form, one can also share five years of patches to a software platform combining thousands of modifications, devoid of context and correlation. The sharing happens, but the original purpose is not achieved. There is no point in forcing people to do something they have not embraced as worthwhile on their own. Particularly not in the large scale collaboration spaces. Instead of calling for lawyers and lawsuits, true community building happens by converging on common goals and shared practices.


Community Culture

The true powerful approach to code sharing is to build a culture of collaboration. Such culture can be based on self-interested arguments: it is better for all the participants when each one of them contribute to the common pool of resources. This cooperation mechanisms can easily be integrated among competing actors, and even adversaries, as Robert Axelrod described in detail in "The Evolution of Cooperation".

This economic context, the "Governance of the Commons", was the field of study of Elinor Ostrom, who received the Nobel Prize in Economics in 2009.  Here again, the Heartbleed bug is a case in point. The problem at its core was not the licensing. The problem at the core of the OpenSSL community is a lack of Community Building (not necessarily to the fault of the few developers in the community). This community should have several hundred developers, but instead it only has three and a few tens of occasional contributors. Shame on all of us, who daily use SSL, but never bothered to raise our hand to contribute to the project. Double shame on those who now dare to point fingers to the OpenSSL community, but never volunteered to review code patches, run tests, nor improve documentation for the project.


The True Goal

The true goal of open source is the active cooperation by a large distributed community of contributors. Software is not the purpose. Software is a subproduct that happens as the secondary effect of cultivating a healthy community. In order to get high quality, robust, innovative software, one must first build a healthy, dynamic, creative, agile, welcoming community.

One must build a space that attracts the best minds, that let them connect with complementary individuals, and that eliminates all the bureaucracy and frictions that prevents contributors from interacting with each other.  A space where contributions are celebrated, recognized and appreciated. A space where those who do the work make the decisions that affect the work (a Meritocracy / Docracy). Such space is to be driven by Unmanagement, through the self-governance that emerges when a groups has clarity of purpose and shared goals.


Licensing Role 

The role of licensing in a true open source community (a healthy peer-production environment) is to:

1) Provide clarity regarding the rights of the recipients of the work.

2) Eliminate the friction to collaboration created by exclusive rights, such as copyrights and patents.


Licensing is not there to create the full cycle of collaboration. It is simply too much of a flimsy instrument to achieve that. The only thing that licensing is barely able to do, is to reduce the friction in the flow of collaboration, and in doing so, removing the obstacles created by obsolete modes of production (such as the industrial revolution approach to publishing), and enabling the actual massive collaboration that open communities can achieve.

In short, licensing is just a bit of lubricant, in the machinery of the peer-production economic model.


Culture is the True Engine

The power of production is the Community Culture. Defined by a small set of social rules, since abundance of rules is self-defeated by creating confusion in the community, and wasting the time and energy that could have been dedicated to collaboration, that now gets absorved in the self-contemplation of rules, and its bureaucratic administration.

The core of an effective Community Culture involves

  • Common Purpose
  • Shared Goals
  • Collaboration Mindset (The Prisoner's Dilemma)
  • Clear and Simple Rules
  • Self-Governance
  • Open and Rapid Communications


The Concern

Licensing discussions drain the energy of open source communities, and in most cases are simply instances of Bike Sheding.

That is, they are an apparent easy approach, that gives the illusion of providing a solution to a complex and arduous problem, and therefore become an easy surrogate for avoiding working in the true problems at hand. The group puts its energy on profusely sharing opinions on the "color of the bike shed", while the "nuclear power plan issues" are sorely neglected.

Licensing is just lubricant to the engine of creation. Licensing does not produce collaboration, it is simply one of the many ingredients that make collaboration easier.

The true rules of the land in open source communities are codified in the Community Culture, which is established by actions (not words), and reinforced by continued practice of such actions, accompanied by the celebration of their results (the Tales of the culture).

The way to build an environment of collaboration is to share, share contributions, share them early and share them often. Recognizing them as they arrive, and acknowledging the corresponding contributors (credit when credit is due). Contributions are not only code, (e.g. the misleading notion of donations, that are again rooted in the Manufacturing Delussion). Contributions include code reviews (what would have prevented the Heartbleed bug), documentation, training, coordination, welcoming of new participants, assistance to new users, and coordination of all of them. It is a lot of work that must be done every day, consistently over long periods of time. That's maybe the reason why many prefer to engage in the low effort of Licensing discussions, cultivating grudges, and ruminating arguments, instead to embarking in the real work of Large Scale Community Building.


With that... I will now go back to the real work:

Preparing training materials for welcoming the new generation of thousands of developers that we need in this community.



Source code access protects users - lack thereof endangers them

Michael O'Neill's picture


Heartbleed shines a light on some important topics for open source communities. Luis' post does a great job discussing the impact that the community culture has, far beyond the choice of license, and to my mind this is an important topic for the OSEHRA community.

When we zero in on the impact of license choice, however, I think it's important to note that while permissive licenses such as Apache 2.0 and the OpenSSL license allow derivative works to be distributed without source code, they do not allow redistribution (in any form) without attribution.

In your example, a vendor would have to disclose that they have bundled OpenSSL with their application. 

I certainly agree with your assertion that vendors who ignore the license terms of the software they use and who do not patch serious defects in their products put their users at risk. Such vendors will undoubtedly put their users at risk regardless of the type open source license involved.




Copyleft licenses preferable to permissive for infrastructure

K.S. Bhaskar's picture is an example of the continued fallout from Heartbleed.

This is clearly a case of software vendors (Microsoft and Juniper) behaving responsibly - although later than most major infrastructure vendors to the Heartbleed patching party, they did eventually come through.  But it does point to one issue: the permissive license used by OpenSSL did not obligate MIcrosoft & Juniper to disclose their use of OpenSSL, and they could have chosen to remedy the defect in a future patch cycle, or perhaps even not at all, which would have left their user base vulnerable since an unpatched Heartbleed is easily detected by an attacker.

Although a software developer wanting to incorporate open source software in a product might well want the most permissive license, or even public domain, someone responsible for infrastructure is better served by a license with a strong copyleft that requires any provider of infrastructure - open source or proprietary - to disclose the use of open source software and provide source code.  For infrastructure I am responsible for, I'd rather know that there is a vulnerability, even if unpatched, than to not know about a vulnerability.  At the very least, if I know that it's there & unpatched, I can think about and take precautionary measures or evasive action; if I don't know it's there, I'm sitting waiting to be blind-sided.