We are examining the benefits and risks of open source licensing to small software companies like mine. In this post, I'm going to present what we've learned and questions we have about open source licensing in order to elicit feedback (comments, ideas, suggestions) from our readers.
What is Open Source Licensing?
First, for those who don't know, let me define what the term "open source" software licensing means. It is, in essence, a variety of licensing schemes in which the owners of copyrighted or patented software let others use and distribute the software under the terms of a particular license. There are many different open source licenses, which vary widely in what is free and in what others may or may not do with the software.
Dan Bricklin (inventor of the first electronic spreadsheet, Visicalc) describes it this way:
In pretty much all cases of open source, the user of the software gets access to the source code [i.e., the underlying instructions] used to create the software. Differences are in what the user can do with that source. In many cases they can make modifications to the software and use the software so modified. In some cases they can distribute the changes, in other cases they can only let the original owner know of the changes to be possibly added to the next release. In some cases the users can distribute the software (with or without changes) as they please, in others they can only distribute it under certain conditions, such as without fee and with public access to the modified source.
Some of the desirable 'freedoms' for the software from the user's viewpoint include:Some of the least restrictive licenses seem to be promoted by the Open Source Initiative (OSI). The licenses OSI approves allows anyone, for any purpose, to freely modify and redistribute the software in its original or modified (called "derived") form. Other open source licenses have restrictions. For example, while the Creative Commons Noncommercial-Share Alike 3.0 license grants licensees the right to freely share (copy, distribute and transmit the software) and remix it (make modification to adapt it for their particular needs), it has the following requirements:
Some of the restrictions that people put in their software licenses include:
- The freedom to run the program for any purpose
- The freedom to study how the program works, and adapt it to your needs
- The freedom to redistribute copies
- The freedom to improve the program, and release your improvements to the public.
There are many arguments about the reasons why various combinations of rights and restrictions should be in a given license. While one may argue about which are "better" for society as a whole or for the company in particular, there is a choice to be made and creators of new software can make them as they please. [Reference]
- Requirements to maintain the attribution to the original author(s) along with the software
- Restrictions on the type of license that may cover redistribution
- Restrictions on the type of licenses that may cover other software included with the software when redistributed
- Restrictions on the uses of the software, such as non-commercial only.
- Licensees must attribute the software (also called the "work") in the manner specified by the licensor, such as stating the licensor's name and contact information
- The work may not be used for commercial purposes (the licensee cannot sell or otherwise use the software to make a profit)
- Anyone who alters, transforms, or builds upon the work must use the same or similar license as the current one if they with to distribute the resulting work to others.
Note that there are dozens of other open source licenses, including those that restricting derived work and free sharing. Very complex indeed!
What are the Risks of Open Source to an Inventor?
With all this complexity, why would a software inventor want to license an application as open source? After all, there's considerable risk in doing so.
Being the inventor of the PHP system and head of a company, due diligence requires that I consider how we would survive if we give away our invention for free after spending tens of thousands of hours of development effort on top other substantial costs (i.e., two decades of overhead, legal fees, etc.). Wouldn't it be business suicide to (a) reveal our trade secrets to potential competitors who have much deeper pockets than we do, (b) give them the right to use our patented processes and copyrighted materials for free, and (c) allow them to make a profit from our work without any compensation to us?
Well, some of these issues can be mitigated by using a license such as the Creative Commons Noncommercial-Share Alike 3.0. But even if other software vendors are prevented from stealing and profiting from the inventor's ideas, open source does not necessarily mean the inventor or his/her company will be fully protected and will gain financially from using open source licensing. So, do the benefits of open source outweigh the risks?
What are the Benefits of Open Source?
Despite the risks to the software inventor, I like open source licensing for a number of reasons. For one, it has the potential to reach and engage a large body of collaborators who can create a community who donate their time and expertise to expand and improve the original software system--and do it, ideally, for the common good. This is very important to us for several reasons:
- Since the PHP system has been built from the "bottom up," it is designed to evolve continually by incorporating and integrating an unlimited diversity of data & information, analytics, and decision tools to help fill the knowledge void in a way that improves worldwide health by addressing the specific health needs of people across all cultures and nations. But being a small company with a discontinuous/disruptive innovation, and lacking the means (the money, work force and other resources) to organize people around the world for such international projects, means we need a cost-effective way to collaborate with other software developers and subject matter experts (clinicians, researchers, educators, translators, etc.) around the globe. Joining forces with international groups of collaborators across all healthcare disciplines (including all forms of physical, mental and mind-body illness, wellness/prevention, Eastern and Western approaches, and alternative medicines) would:
- Enable the PHP system to realize its potential to provide a wealth of valid, reliable information that promotes the development, sharing, and use of vital health-related knowledge tailored to the people's specific needs throughout the world.
- Reduce development costs, optimize usability, promote region/culture-specific customization and enhancements, and increase product security and reliability.
- An open source approach also promises to move us toward accomplishing our company's core mission: To promote better health and wellbeing worldwide--including addressing the needs of the poor in all nations--thorough better use of better knowledge. We believe our technologies enable us to achieve this mission because it offers a cost-effective way to bring together loosely connected networks of people who share information, models and knowledge via a peer-to-peer (node-to-node) communication architecture. Because our technology consumes minimal resources, there is no need for expensive broadband, high-power computers, or costly software architecture. In fact, all that's needed in most situations are low-bandwidth (e.g., slow dial-up) e-mail and a desktop (or web-enabled) spreadsheet application. The e-mail and spreadsheet software handle the automated collection, exchange, integration, analysis and presentation of huge amounts of cross-disciplinary health information. In addition, they provide comprehensive decision-support tools enabling consumers and their sick-care & well-care professionals to make better, more reliable diagnostic and treatment decisions. Where money is tight and conservation of resources is important, costly/complex solutions aren't viable, but our solution is.
Additionally, open sources benefits end-users (consumers/patients, healthcare practitioners, hospitals, wellness coaches, researchers, etc.) by avoiding vendor lock-in, lowering costs, and delivering more reliable products through code that has been peer-reviewed and improved.
Is Embracing Open Source a Way to Realize Our Vision?
The potential of open source for improving worldwide health, therefore, is enormous! Yet despite all the benefits, reality dictates that a software company must make money to survive. It's tough enough trying to introduce discontinuous/disruptive technology because it threatens the status quo, requires a paradigm-shift in people's way of thinking, and calls for expensive "missionary marketing" (in which market demand is created when no one knows you exist). The brute reality is that I've been struggling for the past 18 years—at great personal expense and family sacrifice—to have our innovation widely recognized as a useful tool for improving healthcare value (higher quality at lower cost). This has not been due to any defect in our technology, but rather to the reluctance of institutional investors to back the long-term development and marketing of radical innovations. Take, for example, this quote from one investor group: "We applaud your motivation and intentions to create a comprehensive system that would certainly be helpful to society and provide a well needed 'solution' to our healthcare system. However, the business plan … may be far too ambitious, and the…risk…exceeds our comfort level."
So, while we've been making steady progress for the past two decades, we have not come close to realizing our grand vision of helping make the world a better place by improving the health and wellbeing of all peoples because we've lacked the considerable resources needed to turn such a vision into reality.
The question now is: How can open source licensing enable us to survive financially, so we can continue on our noble mission through international collaboration?
One thought is to sell consultancy services to other software developers, e.g., by offering workshops, courses and training sessions to those who want to learn how to develop and improve PHP-based applications. Another is to sell the PHP system to commercial clients under non-open source licenses (including low-cost software as a service models), along with our libraries of assessment questions. In addition, we would offer our patented CP Split™ technology (which describes a unique way to distribute information using a spatial syntax* data structure) under an open source license as a component of the PHP system only, and we would license it for a small fee for development of any other applications.
Well, that's about it for now. I welcome any feedback about open source risks and opportunities, as well as specific suggestions as to a path forward.
* Warning – This footnote is very technical. The term "spatial syntax" is a shift from the traditional paradigm based on (a) tabular/tuple data organization models used by relational databases and (b) markup tag definitions used by XML documents. Instead, it uses predefined data arrays stored in delimited text or spreadsheet files, which are then rendered using templates that apply formatting instructions based on the data locations/positions (e.g., referencing the data by their cell locations in a spreadsheet). This "spatially-based" paradigm is a proven disruptive technology. What makes it proprietary is that it uses a method for spatial addressing in which a rendering template, which contains formatting instructions: (a) consumes a data file whose contents have been arranged in such a way that the template "knows" the spatial positioning of each element in the data file, and then (b) applies the associated formatting instructions based on the data locations.
There are multiple ways to generate a data file that enables an associated rendering template to use spatial addressing to apply formatting instructions to the data elements. Thus, this method goes beyond mere spatial addressing, and on to establishing associations between such a "report-ready" data file and its corresponding rendering template(s).
[Note: To leave a comment, please make sure cookies are enabled.]
Go to next post