Open Source Considerations


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:
  • 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.
Some of the restrictions that people put in their software licenses include:
  • 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.
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]
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:
  • 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.
The licensor may, however, give permission for these conditions to be waived.

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.
One way open source licensing would enable us to offer our technologies to help people in underserved regions is by affiliating with non-profit organizations such as Open Health Tools, Partners in Health and Nyaya Health.

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.

Part 2
---
* 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

Open Source Considerations (continued)


Below is a compilation of the helpful comments I've received from readers of this blog in response to my recent post on Open Source, along with some comments and questions.

Patent-Based Dual-Licensing Open Source Business Model [PDF available here]

I found this model intriguing since the inventors/licensors of patented software would "…distribute to the public, under open source licenses, software that embodies our patented inventions, and we will seek to encourage those who improve our software to do the same. [They] will encourage the creation and distribution by others of free and open source software that embodies our patents without fear that [they] will sue them for patent infringement. And at the same time, [they] will implement a licensing model that allows inventors and authors, and the universities and research institutions that sponsor them, to profit when their patented inventions and copyrighted works are used in commercial and proprietary products and activities."
While it allows for "… (1) the making, use, sale, offer for sale, importation, licensing or distribution of open source software; [and] (2) the making or use of software or hardware for experimentation, research or teaching … Companies and individuals are free to modify their open source software in private to develop new applications, but once they put that patented software into production, they must seek a patent license from [the licensor]." In addition, it "… excludes proprietary software and hardware embodiments of [the] patents."

I read this to mean that when licensees want to sell any application they've developed that incorporates the patented invention, they must pay the licensor "...reasonable royalties based upon the value-add of [the] patented technology." Also, any derived work must be distributed to the public as open source software.
Several readers commented that I go with a dual license containing a GPL for the OS community and a commercial/business-like license for a fee because it offers the benefits of community support and transparency, which helps develop more reliable products (e.g., through bug tracking), continuous quality improvement, more coordinated development, more satisfied customers through ongoing feedback. The down side is lower profit since revenue is limited to fees generated as a service provider, royalties for the value add, and a smaller market of potential customers since members of the OS community have the rights to sell into the same market.

Another potential downside is that GPL users can charge the licensor a fee for any patches they develop that improves the code. A suggestion is to put the code of the commercial and open licenses in different modules, which are loaded at runtime and thus unavailable to the GPL user. Commercial users that have access to the source code, on the other hand, would be required to submit patches with authorization for the licensor to distribute under commercial license.

Still another downside of GPL dual-licensing is it discourages the distribution of code since developers don't get some of the profit when others sell it under commercial license. That's why it was recommended that a very permissive BSD license be used in the portions of the code to which the licensor may want to add proprietary extenstions.

I'm not sure I have this all correct?

"Freemium" Business Model [link]

While not an open source (OS) model, per se, the Freemium model, the basic product is given away for free, and upgrade features are sold to consumers as "premium offerings." I suppose this is similar to the "loss leader" model. This is a good way to stimulate viral marketing (work of mouth) and it can work for a software company as long as the consumers are willing to pay for the upgrades and are not content with only the free version.

BeeKeeper Model [link]

 
This combines an open source project and a proprietary software vendor in a Professional Open Source Software (POSS) model. "POSS companies exist as an exchange system between two sets of consumers: an open source community (motivated by mutual contribution) and a mainstream market (motivated by economic rewards). Organizations in need of support, services, training etc contribute financially for those services as paying customers. That money is used by the POSS company to pay for full-time resources (engineers, product managers etc.) whose efforts … end up as open source software, freely available to an open source community. The open source community contributes to the software by helping improve the design, functionality, quality, translations, and documentation of the software. The improved software attracts more customers and the cycle continues, hopefully perpetually. In this model, all three parties gain:
  • The community gains open source software they can use for their own purposes. This software has more functionality and more resources than a 'pure' open source project could provide. In this way the community profits directly from the POSS company and its customers.
  • The customers gain higher quality software at a better price. The customers profit from the open source community's ability to produce high quality software.
  • The POSS company gains by growing and increasing its valuation as a result of keeping both sets of consumers content."
An interesting model, but I'm not clear about the constraints on the OS community's rights to sell derived works.

Conclusion and Next Steps

There are many ways to go. At this point, I'm most interested in the Dual-Licensing Open Source option, and utilizing some aspects of the Freemium model (since they appear compatible). I'm not clear as to the best way to handle the intricacies when it comes to the OS part of the dual licensing, however.
Go to next post

An Open Source Proposal


In this post, I discuss the things we are considering as we develop an open source proposal. Our decision process is more complex than most other OS companies since we have put over two decades of work building an architecture and wide range of diverse applications that incorporate a patented disruptive technology. I welcome your feedback.

In order to clarify our current mind-set, I've included a brief description of our existing source code modules, data library modules, and spreadsheet models that comprise our software applications. I also describe the basic components of our asynchronous, publisher-subscriber, node-to-node architecture.

Source Code Modules

All code modules in our applications are written in currently Excel Visual Basic for Applications (VBA), and some also include Visual Basic (VB) routines. These macro modules, along with Excel Active-X user forms, can be converted to .Net without great difficulty (if desired). Following are the functions these modules provide.

Data Source Access

  • SQL queries
  • XML parsing
  • X12 parsing
  • HTML parsing
  • Other document parsing
  • Data transformation
  • Consumption of database-generated reports
  • Retrieval of documents via hyperlinks
  • Access to web sites.

Node-Based Workflow Functionality

Overview: As described below, our nodes use the CP Split™ technology to separate content from presentation in spreadsheet models. By first sending a report-template file to a subscriber, the data can then be sent in a delimited text file (or an SMS text message, etc.) independent of formulas and graphics. Even greater value is obtained when using a series of nodes to ship data from one person to the next, with each person contributing and using what they can.

The nodes use macro-driven spreadsheet template files. These templates execute specific publisher and subscriber node functions based on the particular models being used for data access/input, processing, delivery, and presentation (reporting). Following describes the basic functionality of the nodes' spreadsheet template models.
Basic Publisher Node Functionality
The Publisher Node Template Files (Pub TF):
  • Create Content Files, which contain the content (data and information) elements used to generate reports. These files are unique in that they include information conveying the location of each element within predefined formations (patterns) in a spreadsheet used to generate reports (the "destination spreadsheet"). The Publisher Node's Template File (Pub TF) creates these Content Files by first obtaining, transforming, validating, integrating, and analyzing content elements from all required sources. It then conveys the location of the content in the destination spreadsheet by adding metadata or by arranging the content elements in a particular manner.
  • Transmit Subscriber Node Template Files (Sub TF), which are described below, to authorized Subscriber Nodes. This is done for new Subscriber Nodes, and when a Sub TF is modified. In addition, Publisher Nodes transmit the Content Files corresponding to each Sub TF, whenever new content or modified is added. This file transmission process is currently done automatically via macros by sending encrypted e-mail attachments through MS Outlook.
  • Generate Pub TFs and Sub TFs: Components of a wizard guiding development of template files currently exist.
Basic Subscriber Node Functionality
The Subscriber Node Template Files (Sub TFs):
  • Consume the Content Files sent from Publisher Nodes by extracting them from the e-mail attachments they receive
  • Present interactive, asynchronous, desktop reports, defined by models in the Sub TF, through a Viewer, which applies formatting instruction to the data and information extracted from one or more Content Files.

    Rules/Algorithms

    The Pub TFs and Sub TFs contain rules (algorithms) that execute logic and computational processes. They are used in conjunction with spreadsheet formulas to provide decision support, alerts, warnings, role-based views, etc.

    APIs

    Enables connectivity with other applications.

      Data Library & Content Modules

      These modules contain no programming code.

      Master Data Index

      • Hierarchical evergreen list of assessment items defining data entered manually and obtained from other sources
      • Uses a Dewey Decimal type Indexing system
      • Included branching logic to speed manual data entry.

      Instructional/education materials

      • Original text
      • Links to web-based materials
      • Incorporation of third party materials.

      Types of Content

      • Health risk appraisals
      • Signs and symptomology (physiological & psychological)
      • Life problem assessment
      • Emotional health & psychological wellbeing
      • Treatment-specific information
      • Wellness information
      • Mind-body connection
      • Demographics and personal history
      • Problem management guide
      • Decision support and educational materials.

      Spreadsheet Models

      Personal Health Profiler™ Application (the PROFILER)

      The PROFILER contains spreadsheet models consisting of data sets and rules/algorithms that are used to:
      • Associate signs/symptoms with medication side-effects and adverse drug interactions
      • Support sick-care diagnosis and treatment decision
      • Support well-care health appraisal and intervention decisions
      • Assess treatment progress and outcomes
      • Assess deviations from evidence-based protocols
      • Present role-based views for:
        • Consumers
        • Providers/Clinicians
      Other Spreadsheet Models
      Every application has its own spreadsheet model. The next section briefly describes our other applications in healthcare and other industries.

      Applications Currently Available

      We currently have both healthcare and non-healthcare products and prototypes as described below.

      Healthcare Applications

      The PROFILER
      The Personal Health Profiler comes in different versions, which are tailored to the needs of all:
      • Consumers
      • Providers
      • Researchers.
      Other Healthcare Applications
      • CarePathWays Plus™ (CPW+™)—A clinical pathways application that self-adjusts to diagnostic criteria and provides sophisticated outcomes and variance analyses to drive continuous quality improvement
      • CCR+™—A continuity of care record with advanced decision-support for information sharing and care coordination between primary care physicians and specialists working with the same patient
      • Care Order Management System™ (COMS™)—Facilitates the establishment, delivery and evaluation of plans-of-care in the trauma center and manages facility resources (including staff, beds, equipment and materials) to help assure patients' receive the care they need
      • LifeChart™ tracks and displays concisely, on a pictorial timeline, the relationship between treatments delivered (medications and procedures), patient health status trends (changes in physical and mental health), and influential life events/stressors
      • Personalized treatment guidelines/plans based on assessment/diagnostic data
      • Care management & advocacy system for helping discharged patients with chronic & severe mental illness receive the services and benefits for which they are entitled.

      Non-Healthcare Applications

      Include diverse software for education, oil exploration, financial services, space exploration, wholesale/retail.

      Our Proposed Offer to the OS Community

      Being there are multiple applications, code modules, content modules and template models, we are considering a stepwise process in which we start by making the basic/core components open source under a suitable OS license (yet to be determined). Then, depending on the response of the OS community, I would consider expanding our offering. Here's what I would like to provide initially, which, of course, may change based on the feedback we receive:
      • Since one of our top goals is to offer an exceptionally cost-efficient way to exchange health information in both poor nations that lack a robust communication architecture, as well as more built-up countries, we would offer the source code for our node-to-node (i.e., application-to-application) architecture, which includes our underlying CP Split™ technology patent and e-mail based file sharing.
      • Since the clinician version of the PROFILER is more closely related to the OS work being done on EMR/EHRs, we would offer its source code under the same OS license we chose for the Nodes.

      Our Request of the OS Community

      Source Code Development

      I believe there would be real benefit in collaborating to expand and improve the source code of the PROFILER and Node-to-Node architecture. This includes:
      • Browser-enabling all functionality
      • Improving and expanding the Excel Visual Basic code for asynchronous desktop use
      • Establishing connectivity with all EMR/EHR and PHR databases.

      Content Modification and Development

      • Translate the content modules into other languages
      • Create new content, and modify existing content, through collaboration with:
        • Consumers/Patients
        • Academicians/Universities
        • Clinicians of all types
        • Research scientist.

      Models Development

      Share, use, evaluate and continually improve the spreadsheet template models.

      Go to next post

      Questioning Open Source Motives: Can a Corporation be Virtuous?

      An interesting article about open source appeared last week in the ZDNet blog post: Open source as the villain in its own story.

      I posted a comment, referencing our resent disucssions and recieved this challenging response:
      “What does it disrupt? What "potential benefits to humanity" could it possibly have (disrupt) while it is "minimizing (disrupting) risk to shareholders", whose sole motive is making money (according to present Corporate business models)?”
      My reply follows:
      All excellent questions, especially since you know neither my company nor me, and since we live in a society in which capitalism has become “perversely commercial” and “pathologically mutated” (see http://curinghealthcare.blogspot.com/2008/02/us-healthcares-perverse-commercial.html).  
      It’s no wonder many of us believe virtue is absent from all corporate business models, and that greed and ego are people’s prime motivators.

      In our case, however, we’ve been struggling to survive for the past 15 years because we follow a business model whose mission is focused on helping make our world a better place by improving the health and wellbeing of all by bringing greater value to the healthcare consumer through better use of better knowledge.

      Unfortunately, our insistence to remain true to this virtuous business model has, in fact, hurt revenue. That’s because our healthcare system is not built to bring value to consumers; it’s actually quite the opposite (see http://curinghealthcare.blogspot.com/2007/10/think-small-and-dont-rock-boat.html).

      A primary reason we’re considering open source is that we believe achieving our mission can best be served by opening up our software worldwide through licenses that sacrifice big profits for the potential benefits of collaboration with international communities of consumers, clinicians, developers, and researchers.

      One way we envision our technology helping poor nations is by providing an exceptionally cost-efficient architecture for sharing healthcare information. Instead of requiring continual connectivity to the Internet, high bandwidth communications, and expensive software systems with centralized data storage, all our disruptive technology needs is occasional e-mail over low bandwidth connections and a spreadsheet. For many regions of the world, our low cost, low resource consumption, peer-to-peer solution makes very good sense.

      Bottom line: Making money it essential to any corporation (or else you’re out of business), but it need not be the sole mission of a company. True, with the way capitalism in our country has devolved over the years, it’s not easy at all to be a virtuous corporation; in fact, it can be very difficult, at least that’s been our experience. But I’d rather “go down with the ship” than to profit financially by sacrificing our ideals.
      Go to next post

      Free vs. Commercial Open Source Software


      I'm now back focusing on open source (OS) and intend to offer an application to the OS community, hopefully this week.

      By coincidence, I just read a post to the OpenHealth organization about a new wiki at http://freeopensourcesoftware.org/. In it, Bill Stewart wrote an excellent article in which he compared "Free Open Source Software" (FOSS), which is free in all versions, "Commercial Open Source Software" (COSS), which might include FOSS components, but requires fees for some code.

      The article made the point that COSS isn't "true" open source because, for example, COSS vendors typically "intend to profit from proprietary add-ons to their … software." To FOSS purists, this is an ethical dividing line: While they wound not "deny others the right to make a living providing value-added open source support services," they are concerned about where this is heading. They ask,
      "If there is a valuable principle at stake here, if open source is a precious gift to the world and future generations, what can or should be done about these developments?"
      The article continues:
      While business involvement with open source can be productive, many remain seriously concerned about a development that has blurred the lines around core principles -- the increasing proliferation of companies that call themselves "open source" because they provide open code and a free version of their software, but require a commercial license and fees for advanced versions. The increasing popularity of this kind of software, sometimes inaccurately called "dual licensed" open source … is becoming a popular open source business model, and increasingly of popular concern.
      While I understand this issue and do firmly support working for the greater/common good, I have trouble with an apparent double standard that states it's OK to make money selling value-added open source support services, it's not OK to make a dime selling value-added code! Maybe I'm missing something, but I don't understand this dichotomy.

      Let's say someone spends 15 years of his own time (without pay) inventing a software process that no one else ever conceived, and then he spends tens of thousands of dollars obtaining and maintaining a patent for that process. Let's also say that software code he's using to run this process can be re-written in many different ways and in many different programming languages.

      Now imagine the inventor deciding to offer his patented process, his current version of code, and his support services to the open source community under a dual licensing agreement. This agreement states that it's OK to use and modify the code in private to develop new (or improve) applications, but once any product containing the original or derived code is put into production (i.e., for sale), the vendor must seek a commercial license from the inventor.

      According to the FOSS-based double standard above, the inventor is being unethical because the original code should be offered free, even if developers sell their own applications containing the inventor's code and patented process. And the inventor should provide all his applications, enhancements, and add-ons for free, rather than selling them to earn a living. Thus, only if the inventor has an opportunity to offer value-added services (e.g., training workshops) would he survive financially.

      My question is: What makes the inventor's intellectual property (the patented process), and the thousands of hours spent programming the software code, less worthy of monetary compensation than the training course? Why is it unethical for the inventor to collect a reasonable royalty/licensing fee from vendors who use the patented process and code in the products they sell? Can anyone help me with this?

      Go to next post

      Looking for Balance in the Open Source World


      I'm still communicating with several intelligent and informed people about open source, freeware, and FOSS and COSS licensing. There has been a good deal of confusion and complex nuance because, it seems to me, my situation doesn't fit cleanly into the common scenario.

      On the one hand, I totally agree with the people who say (a) doing good for the world is a top priority and (b) there's something wrong with focusing solely on maximizing one's profits when it means withholding an important innovation from those who need it badly, but can't afford it.

      On the other hand, it's self-destructive and harmful to one's family, investors, and other stakeholders to "give it all away for nothing." If that were to happen, the people who put their money and trust in you, those who committed their time and effort, and loved ones who depend on you would suffer unnecessary loss and pain.
      What's needed, imo, is a balanced approach … one that would likely be a win-win for the world, for my company's stakeholders, and for my family.

      As I now understand things, the typical FOSS open source (OS) or freeware license gives software developers and users the right to use a software program's code in any way they want at no cost. In the more liberal licenses, they can build the code into another program and use if for their own business, or sell it to others for a profit. Or they can even take the original program and use it or sell it just the way it is, without having to make their own contribution to the OS or freeware communities.

      In contrast, a typicall COSS license requires a fee be paid to the developers of the original software if that program is used in one's own business or if it is sold to others.

      When a patented process is used in a software program (e.g., see http://www.nhds.com/products.html), things can get more complicated; and when that patented process is used in multiple programs of different types, it can be even more complicated. Why? As far as I can tell, it's because FOSS/freeware models were designed for the free use the code of a single type of program; code which is copyrighted, but rarely (if ever?) tied to a unique patentable process.

      So, being the CEO of a company with a patented process applicable to a wide variety of software programs across many different industries, and I don't know how broadly releasing rights to that patent will affect my company, I cannot in all good conscience just "give it away and hope for the best" … even though I'm deeply committed to helping make this a better world.

      I am, therefore, leaning toward a "limited release" of my patent process in which only one software program is licensed as freeware (GPL/AGPL) or another type of FOSS open source (yet to be determined). I'm also considering a suitable COSS license for other programs, or for the general use of the patented process. Some combination of these licenses would bring balance, it seems to me.

      Go to next post

      Open Source Software and Patents: An Uneasy Journey of Discovery and Understanding


      Over the past three months, I've been communicating at length with several leaders in the Open Source Software (OSS) community about how best to license software patents in a way that supports the goal of OSS developers, users, and distributors. I've learned a great deal along the way about the uneasy relationship between OSS and software patents.

      Briefly, OSS products:
      …are systems whose human-readable ("source") code is always freely available to anyone who is interested in downloading it. This is in contrast to most commercial software, whose source code is considered intellectual property and a trade secret not to be disclosed. Advantages of open source include availability, extensibility, and the opportunity for peer review. Open source products are made available under a variety of licenses. …
      Open source solutions have a number of advantages for a healthcare enterprise. The collaborative sharing of ideas and concepts practiced by users of open source software can create 'communities' of developers, partners, testers and users who interact with each other to further improve the software. This can speed up the development process, bringing in skills that a single software vendor would not be able to provide. And the community can also provide an alternative, though unconventional, avenue for technical support….At the data level, an open source software application does not strand critical health data in a proprietary format. [Reference Link]
      There are two types of OSS licenses:
      • "Permissive" licenses—also called the "BSD style" license, come in many styles. They allow "derivative works" (different software programs in which some OSS code is embedded) to be used in proprietary (i.e., non-open source) software programs, which, I assume, makes BSD a type of "Commercial OSS (COSS)" license.
      • The "Copyleft" license, which comes in only one style, and is promoted by the General Public License (GPL) published by the Free Software Foundation. Unlike the BSD licenses, the GPL requires the original source code and all derivative works to be free and open to anyone for any purpose, that is, they can never be used by proprietary programs. The GPL is one of about 50 different Free Open Source Software (FOSS) licenses.
      The advantages of each is discussed in the Reference Link above.
      OK, my conversations with leaders of the Free Software Foundation made very clear the deep-rooted resentment their community has against software patents. They claim that:
      • ALL software patents (but no other types of patents) are "evil"
      • ALL software patents are invalid or trivial, i.e., prior art already exists, but the patent office didn't realize it, or else the patent is for something that is obvious given the state of the art
      • ALL people and companies who (might) sue for infringement of their patents are "predatory, unethical, greedy, freedom-destroying gangs of bandits" who don't care about hurting the world in order to make a quick buck at others' expense
      • ALL software developers and distributors who use free software must be protected from lawsuits by any patent-holder, even if the developers and distributors make a profit by use of someone else's patented code/techniques.
      Why do free software supporters have such a strong view and adversarial feelings; are they justified?
      As I understand it, there has been a rash of invalid/trivial software patents granted in recent years. Take Amazon's 1-click technology, for example. This patent claimed that running a common software process using a single mouse click is patentable compared to running that same process using several mouse clicks. How novel and unobvious is this? Not very! So, the free software community argues that it is justified in defending developers who use any type of one-click technique—or any other patented software techniques—against any infringement lawsuit. [See this link for more] I can certainly sympathize with them and do see their position as valid.

      There is one aspect of this argument, however, that is invalid in my view. It has to do with the way they consider ALL software patents as trivial/invalid, and ALL patent-holders/inventors as evil, greedy, menacing predators. My psychological training has taught me that very few things are so black & white, and such gross generalizations are usually faulty. It would be much more rational to claim that (a) SOME software patents as trivial/invalid, or even MOST if you can prove it, and (b) SOME patent-holders/inventors rely on underhanded, unethical, predatory practices driven by solely greed. Failure to make any such distinctions weakens their case considerably! I've also learned that in adversarial situations, the greatest understanding and best resolution often comes from looking at things from both sides at the same time and then moving toward a "middle ground."

      For example, imagine you are an inventor of a patented software technique that is neither trivial nor invalid, and it has great potential value. If you were ethical and truly want to contribute something beneficial to the world, you want to offer that patented process for free to nonprofit/noncommercial organizations, and maybe even to individuals for their personal use.

      Further imagine that your family has sacrificed a great deal in the past two decades, and that family & friends have helped support your efforts by taking a big risk investing in your company. So, you figure it's reasonable to receive a small licensing fee only from companies and individuals who would make a profit by using your invention in their own software programs. After all, you reason, it's only fair since you've spent many thousands of hours and dollars developing your invention, and you would be helping others make money.

      Now imagine you want to use an OSS license to offer your patented technique to nonprofits and for personal use, and you explain this plan to the FOSS folks. As soon as they hear you would be requiring profit-making companies to pay you a licensing fee, including profit-making FOSS companies, they threaten to defend those FOSS companies if you were to sue them for infringement, should they "happen to get in the way." That is, they would try to destroy you if you sued any profit-making FOSS company that uses your patented technique and refused to pay your royalty because those payments would eat into their profits. In other words, you, the inventor, would be consider unethical, greedy, and menacing because you have no right to restrict the profits others gain by using the invention you worked and sacrificed for years to develop! Maybe it's just me, but this all sounds very counterintuitive and outright unfair!

      If you were that inventor, what would you do … how would you feel?

      Well, that's precisely the situation I found myself in! I admit that it took me a while to figure out why I was feeling attacked, yet was being accused of being the attacker. But since I believe in the value of free open source, and since I do believe the FOSS folks with whom I've spoken are decent and honest people who have been abused by our patent system, I didn't want to become defensive, hostile … or give up. So, I offered several compromises.

      Back in April, when I first started to consider open source, someone suggested the Trolltech "dual-licensing" model. It's an interesting approach, but not appropriate since as it is now written, it is for the dual licensing of copyrighted code and has nothing to do with patents. And then there's a Patent-Based Dual-Licensing Open Source Business Model, but that doesn't apply to me either since it distinguishes between software code alone and code used in a computer.

      So, after lengthy consideration, I suggested that I would be willing to offer the patented technique for free to everyone in the FOSS community, as long as it was tied to a particular type of software program. That is, it could be used in a PHR, for example, but not in an EMR or CCR.

      I was informed, however, that this constraint is called a "field of use" restriction, which is "completely antithetical to the purpose of the license, which is to make it both clear and legally binding that all recipients of the program have every right to copy, modify and redistribute the code for any purpose [italics added], so long as they don't limit anyone else's rights by e.g. changing the license terms on modified versions of the work. Such a modification of the license…would vitiate [i.e., trivialize] its purposes completely [which is why we] use the copyright on the license itself to prevent such modifications."

      I then suggested that I strip out the code in my programs that run the patented technique and offer the remaining source code (which includes trade secrets) for free in a fully functional program under the liberal GNU GPLv3 FOSS license. I would concurrently offer the patented technique under a separate commercial license. Anyone who wanted who wanted to combine the code in the free programs with the patented technique, or use the patented technique in other programs, could do so by paying a small licensing fee via the commercial license. Unfortunately, they didn't see this as a good compromise because it precludes free software developers from using it, which "restricts their freedom."

      Due to the lack of an adequate alternative, I concluded that the safest and fairest way forward is to start by publishing for free (via GNU GPLv3) at least one fully functional software program (including trade secrets); it will not, however, contain any code related to our patented techniques. Elsewhere, I will offer a commercial license for our patented technique to those who want to profit financially from its use. The patented technique will not have any "field of use" restrictions, but will require a small royalty fee. I expect this to be done in the next month or two. Depending on the interest and response from the OS communities, I will revisit this issue and decide what to do about our other programs.

      I believe that by being open, honest and fair with the people in the OS communities, there will be no need for patent infringement litigation since developers and distributors will appreciate my position, realize that we're not "gangs of bandits," and act with integrity for a win-win relationship.

      I welcome any comments & suggestions and will respond, although I'll be available only sporadically over the next two weeks.

      First Open Source Offering: XML to CSV Spreadsheet Converter

      I’m offering my first free open source program; it's under the GPL license.

      This program uses an Microsoft Excel VBA macro to convert XML-based Continuity of Care Documents (CCDs) into a stripped down Comma Separated Value (CSV) file. The CSV contains all the relevant data without formatting instructions, which is literally the most efficient way to distribute raw data. The CSV can then be consumed and formatted by spreadsheet templates or other programs.

      I am looking for help porting the application to OpenOffice or other suitable FOSS applications.
      The Excel macro opens CCD XML file as a form is a spreadsheet, based on formatting instructions from its corresponding XSL file. The macro then strips out the blank rows and table of contents, and then saves the raw data and labels in a CSV file. Although designed to for a particular CCD format, the macro can be modified to work with any XML/XSL file, and is not limited to CCDs.

      You may download a free copy of the file from SourceForge at http://sourceforge.net/projects/convertxmltocsv/