At a recent discussion about the Principles for Digital Development, a common debate took hold of participants: should we keep the Open Source clause in the “Open Principle” that advocates for Open Standards, Open Data, Open Source, and Open Innovation?
Including the idea of Open Source in the original Principles design was to counter the then-common practice of public sector investment in proprietary software and data standards that created vendor lock-in, high licensing fees, and resulted in private gain from public funds.
Over time, the original idea of public funds for public gain was lost and many private companies balked at endorsing Digital Principles that went against their development of proprietary software solutions, regardless of intent or the arguably more important idea of open standards.
Open Standards Are Key
Personally, I prefer a focus on Open Standards, especially when they include open data standards. Email is one of my favorite examples. Anyone can send anyone else an email using the open SMTP standard, regardless if you use Gmail (a proprietary software) or Thunderbird (open source) or even PINE (freeware from the 1990s).
See our many posts on the FHIR health data standard.
Open Standards in digital development would direct software companies to store and share data in a common standard, allowing for interoperability between any two systems. Companies could still create Open Source or proprietary software code, but the data could move freely between the two. Also, governments could choose software based on functionality and service, without being locked into using only one provider.
Obviously, there is much resistance to this idea within software companies that benefit from proprietary standards they control. Governments are then beholden to that vendor to view, edit, or export data, which is now the most valuable aspect of a software system.
What About “Open Transfer”?
One idea I proposed is to focus on Open Transfer – a new concept. Open Transfer is defined as the ability of a government to transfer ownership and management of a software solution and its data from one provider to another.
In this situation, a software developer could create whatever proprietary systems or standards they please. However, a government would keep the right to use that solution and be able to transfer usage rights to another software developer. This transfer would include the incumbent training the new manager on the system and its peculiarities.
There is already a clear precedence for Open Transfer in US government procurement. USAID ADS Chapter 318 on Intellectual Property Rights clearly states that the USG has Open Transfer rights to computer software and data for USG purposes.
When a contractor establishes a claim to a copyright involving data produced under a contract, the USG generally is granted a paid-up, non-exclusive, irrevocable, worldwide license to unlimited rights for all such data. For computer software, the USG receives every right it would have with any other data, except that it does not have the right to distribute it to the public.
When the USG has restricted rights in computer software, the USG generally may not use or reproduce it or disclose it outside the USG without permission from the party owning the copyright. The USG may only use or copy the restricted computer software in accordance with the licensing rights the USG obtained (usually including the computers for which the software was acquired and their back-ups).
Sadly, this clause is rarely invoked and its even more rare that an incumbent has the resources and desire to train the next software developer on how to manage and extend the existing system. However, these challenges can be overcome with stronger proposal language and contract management processes.
Open and Transparent Practices
As you saw yesterday, the refreshed Digital Principles talk about Creating Open and Transparent Practices, noting that effective digital initiatives establish confidence and good governance through measures that promote open innovation and collaboration.
Open and transparent practices can include but are not limited to a technical design with open and transparent practices that can include the use of agile methodologies, open standards, open data, open source, and open innovation.
The refreshed Principle notes that when organizations do not prioritize transparency and openness, it results in a lack of or loss of trust. Trust is critical to encourage participation, and without it, people will rationally choose to avoid the risks associated with engaging with digital services and sharing their data – thus foregoing any potential benefits.
So what do you think? Should we focus on open transfer when applying the Digital Principles in digital development? Is that a key open and transparent practice?
I’m not ready to give up on open source as a principle, even if we can’t always live up to our principles!
As far as open transfer, I quite like this concept and do appreciate it being elevated here. The immediate part that I find tricky is whether the government/funder would maintain rights to the old version of the solution or also gain access to updates (thinking cloud-based solutions here). Both realities seem flawed depending on where you are sitting. Also, would the new manager have rights to build upon the solution? @wayan do you have a vision for that dynamic?
I’m also curious what the ICTWorks Community thinks would be required for the current ADS clause to be regularly enforced. That does seem like a great place to start!
When something is entirely publicly funded (not always, but often the case in the development sector), why should it not be usable by the public? Why should anyone (government or contractor) have a monopoly on the future use and adaptation of the work?
The challenge with the principles is that there are no measurements or reporting of how organizations that endorse them on paper are actually putting them into practice.
Wayan Vota raises an interesting concept with “Open Transfer” in digital development. It seems like a practical approach, aiming to balance proprietary interests with public access needs. This could indeed help mitigate issues related to vendor lock-in and enhance the flexibility of government software systems. The precedence from USAID ADS Chapter 318 shows that it’s feasible, though clearly underutilized. It’s worth considering how such a framework might promote more open and transparent practices in software development. What are your thoughts on its potential impact compared to traditional open source models?
Hi Wayan,
I appreciate the problem that the idea of open transfer is trying to solve. While I am a remain huge proponent of open source, I feel that donors, implementers and countries have leveraged that as an end-round to avoid paying for the substantial value the open source software provides. Unfortunately, open source software is as expensive, if not more to maintain then proprietary software. I also fully agree the conversation should really move towards adoption of open standards and be less fixated on license type.
The one problem I see with the open transfer idea is the issue of management and maintenance. If the software can be transferred from one vendor to another but the code is closed / proprietary that raises really big practical issues. Does that mean that creator of the software would be forced to grant access to the code base of the new vendor? If not, you would be forcing the original vendor to maintain the software on behalf of the new vendor that replaces them probably without adequate payment. I can see that going really well 🙂
Fortunately, there already exists an approach that I think addresses some of these concerns. BSL or business source license. While there are various flavors, the idea of BSL is keep a lot of the advantages of open source while providing some commercial protections to the creator of the software. A lot of popular software platforms like Elastic Search and MariaDB have gone BSL to protect them aggregators like AWS who has huge advantages in reselling their software. BSL typically keeps all the code open source (as in available to access) and is free to use in certain situations. Eg. for projects but you can’t repackage and sell as a SAAS service. Most BSL licenses also have it that older releases of the code (eg. after 2 years) automatically become available under a full open source license (typical LGPL). Of note, RapidPro a popular messaging platform in our space has successfully switched to a BSL model.
In the context you are describing above, software could be made available under a BSL license that grants specific type of clients (eg. Min. of Health) a perpetual license to use the software for free. They could also be granted access to the code which could be modified and maintained by the vendor of their choice. Any changes/improvements though in the software would fall under the BSL license and assigned to the original creator of the software. The new vendor would be able to serve the MoH but not able to use the software (without purchasing a BSL license) to compete against the company who invested in building the software on other projects.
This approach helps ensure the donor investment goes to serve the intended beneficiary (MOH) while providing some protections and incentives for software vendors to continue to try and serve this space. It also forces the large implementers, who are increasingly eating the majority of the ICT4D pie, to rethink their approach about software and relationships with software vendors which I would generously describe as extractive as best.
While I like the idea of BSL better then open transfer, I greatly appreciate you raising this important issue. The way we fund technology in our space is fundamentally broken which makes serving this space as a software vendor difficult. Unfortunately, the open source argument has been used very effectively to tamper discussions around the fact that to create a healthy market the usage software needs to be properly budgeted for regardless of the license type.
What are some advantages of prioritizing Open Standards, particularly in terms of interoperability and government procurement?
Here’s a great post on an aspect of Open Transfer:
Works of government may be public by default
Under the Copyright Act of 1976, “Copyright protection under this title is not available for any…work prepared by an officer or employee of the United States Government as part of that person’s official duties.” Although there are exceptions, it is broadly true that software developed by the federal government is in the public domain. Custom software produced for the federal government by vendors is often public domain, but not always. If the copyright is assigned to government—as it really, really should be—then it is generally public domain. (This is governed by FAR Subpart 27.4—Rights in Data and Copyrights. See also the prescribed clause in FAR Subpart 52.227-14—Rights in Data-General: “Government shall have unlimited rights in…[computer software] first produced in the performance of this contract.”)
At a state level, things are much messier. There is no consistency between states, and sometimes no consistency between agencies within a state. Custom software produced by or for state agencies might be public, or it might not be—you’d need to consult a lawyer to be sure.
Open-records laws may require you to turn source code over to requestors
Federal and state open-records laws have often been used to compel agencies to provide custom software’s source code to anybody who asks. It’s broadly true, at a state and federal level, that there are exemptions for releasing records that are otherwise prohibited by law, and every government has a law prohibiting the release of information that could undermine computer security. But if that exemption doesn’t apply, then federal agencies need to turn over the source code, which the recipient is then free to make public. Again, there are huge differences between states’ freedom of information laws, so research is necessary to know how those apply to source code in a given state.