A Perspective of Open Source Licensing Models for the Health Care Industry

Hadrian ZbarceaRecently, I've had several interesting conversations about how business models based on open source technologies apply to the healthcare industry. While a lot has been written on the subject, I aim to provide a concise summary and some of my personal perspectives on the matter. This article discusses the definition of open source technology and licensing models; a second article will discuss governance models and applications in healthcare.

So what is open source?

The definition of Open Source is a bit challenging as it means many different things to different people. The definitions range from a computer engineering definition, to philosophical definitions to business models and collaboration models.

In this article we are going to focus on the engineering definition of open source. From an engineering standpoint, open source means that the source code of a software product is publicly available. In other words, it is open to inspection and modification. The Wikipedia article on open source is a bit inaccurate in that it seems to conflate licensing and collaboration models into the definition of 'open'. Obviously, there can be situations where open source code released into the public domain under no license at all, as well as code produced by one individual without any collaboration. I would assume that the Wikipedia authors ignored these situations as not being very relevant cases. Or, they relied only on the OSI definition of open source. Indeed, the greatest value of open source comes precisely from licensing and collaboration, not necessarily from the 'open' aspect.

Licenses to the Left and to the Right

Despite plentiful discussions and articles around open source licensing, my observation is that understanding of open source in the healthcare industry is still limited. As a required disclaimer, I am not a lawyer, and none of my observations here could, or should, be interpreted as legal advice. I am, however, a long time active member of the Apache Software Foundation (ASF), a code committer and member of the Project Management Committee (PMC) for several Apache projects. I also served as the non-profit organization's Vice President for Fundraising for over three years.

In addition to my work with ASF, I have also contributed code and was a member of other organizations, like OSEHRA, LibreHealth and others, and developed an open source communications platform that can be used for emergencies and disaster response even if the communications networks are down.

Thus from a practical hands-on aspect, I am very familiar with both the positive and negative aspects of using open source by commercial organizations, code related or not.

In reality, it's hard to talk about open source licensing without talking about intellectual property (IP) and copyright. Copyright sums up the rights and obligations that the rightful owner associates with the work. The license describes the rights and obligations of any and everyone else, and can be as broad or as limited as the owner chooses.

Two of the most important rights (and obligations) are the right to make modifications to the original work and the right to distribute the derivative work. 'Copyleft' licenses such as the GNU Public License (GPL) which is a popular one require that all rights applicable to the original work also apply to the derivative work. In this sense, copyleft licenses are said to be viral. That is in stark contrast to the Apache, MIT or BSD licenses, which place no such burden and are known as 'permissive' licenses.

Copyleft licenses are based on the idea that freedom (as in free speech) will spread, and safeguarding open rights in the cascade of derivative works leads to a large body of usable work that will make the world a better place. That may be true, and one could see the appeal of such a principle. However, if we consider a commercial enterprise as an adopter, we have to appreciate the other constraints that companies have, such as protecting their own, added intellectual property in the efforts to compete effectively. It's no wonder that commercial companies frown upon GPL-style licenses.

To make things more complex, there is also an additional model called dual licensing. This is where the owner provides the same work under two different terms and conditions, in this case an open (GPL-style) license and a commercial license. The problem with this is that through the magic of marketing, an organization can advertise that a particular technology is open-source, but by providing a commercial license option (purchasers of which are exempt from the requirements around openness of derivative works), commercial adopters can draw the benefits of a proprietary license that exempts them from having to contribute the code back to the community. Thus many commercial companies that rely on a particular open source code base can well and distribute the code without having to contribute their code back. The practice of dual license, which was popular in the early 2000s, added to the distrust of copyleft license use.

Notably, the dual licensing option is only effectively available when there is a single IP owner. This is because if a particular work has already been available through a copyleft license, all contributors are IP owners of some portion of the downstream work. This means that to make a commercial license an option, all owners would have to consent (possible in theory, unlikely in practice).

Therefore, there is a big difference between IP owned by a large, diverse group (as is the case for the Linux operating system, for instance) and IP owned by a single entity that has the right to dual license. The first safeguards the copyleft principle of a large body of open work available to all, the second bypasses it almost entirely.

Conclusion

The point of all this is that the license matters. It has a direct impact on who will adopt the open source work and what that person or entity will do with it, e.g. redistribute. I have noticed that in the healthcare industry, many projects have adopted copyleft licenses, in particular the GPL. It has been adopted, for example, by open source EMRs such as OpenEMR and WorldVistA). There has been significant global adoption of these projects around the world.

However,in most of the open source EMR projects that have adopted the GPL, the terms of the license have not been enforced. That has led to a proliferation of "derivative works" where a large number of small companies have each their own derivative version of the code and there is little collaboration between those companies and minimal code contributions back to the mainstream code base.

Thus the project and the communities around the projects are fragmented and do not collaborate in the way that successful open source projects have learned to collaborate. Thus licensing is not the only factor when it comes to successful open source projects. There are other factors. The governance of these projects is a major factor. We will discuss governance in the next article.