As we said in our last post, “not all open source projects are digital public goods, but all digital public goods must be open source”. To be open source, there must be distribution terms, or a license, that allows for distribution and reuse. That is why licensing appears as the second indicator in the Digital Public Goods Standard. Licensing determines a DPG’s viability and adaptability – a linchpin of meeting the “public” criteria of a DPG.
However, the process of identifying which “approved” licenses to include in the DPG Standard was, and continues to be, the result of a complex series of debates and discussions. The aim of this post is to share some of that discussion and the thinking behind the licenses that appear in the DPG Standard today. This will provide context for those considering submitting an openly licensed project to the DPG Registry, as well as for projects who are choosing an open license for the first time.
At present, the DPG Standard’s second indicator reads:
|2. Use of approved open source license||Projects must demonstrate the use of an approved open source license. For Open Source Software, we only accept OSI approved licenses. For Open Content we require the use of a Creative Commons license while we encourage projects to use a license which allows for both derivatives and commercial reuse (CC-BY and CC-BY-SA), or dedicate content to the public domain (CC0); we also accept licenses which do not allow for commercial reuse (CC-BY-NC and CC-BY-NC-SA). For data we require an Open Data Commons approved license. You can find the full license list here.|
By design, open source software licenses promote collaboration and sharing because they permit others to make modifications to source code and incorporate those changes into their own projects. They also encourage others to access, view, and modify open source software to build solutions for their own purpose. Read more about why we require DPGs to be open source in our previous blog.
For Open Content we require the use of a Creative Commons license and encourage projects to use a license which allows for both derivatives and commercial reuse (CC-BY and CC-BY-SA), or the ability to dedicate content to the public domain (CC0).
When choosing which licenses to include in the DPG Standard for content, we took into account key considerations. For example, we allow the Creative Commons NonCommercial (NC) clause for content and data, but not the No-Derivatives (ND) clause. This decision was made because ND licenses put restrictions on reuse and adaptation. For example, for content that is under a ND license, translation is not allowed. A NonCommercial license allows for reuse and adaptation as long as it is not for commercial purposes. While this does limit the opportunity for commercial scalability models, we took into consideration that many stakeholders will still be able to benefit from reusing and adapting content that cannot be commercially reused. Furthermore, this increases supply, as many who have invested heavily in content creation will be more willing to use open licensing if they can apply a NC clause.
For software we chose to accept the Open Source Initiative (OSI) approved licenses not only because these licenses are widely accepted, but because they have all been vetted against the OSI definition of open source. The Open Source Definition is a list of ten clearly defined requirements for a license to be recognized as open source. The distribution terms of any software with OSI-approved licenses must comply with the Open Source Definition. Additionally, the vetted licenses undergo a review by the open source legal community. This rigorous process helps to filter out ambiguous or vague licenses that don’t explicitly comply with the requirements. However, the OSI license list is also quite long and only a few of these licenses are used in practice.
The Open Knowledge Foundation has in its open definition requirements for open data in much the same way OSI does for software, including a definition and a list of approved licenses. However, in the open data space many countries have in parallel developed their own open government licenses for data and content, and many of these national licenses have not been approved by the Open Knowledge Foundation. This is something we are working to navigate as we develop the DPG Standard further.
A Note on Up/Downstream Sharing
Presently, in order to be DPG Standard compliant, the open licenses we list apply only to the core or generic project. The type of open license used for the generic project will determine which open license requirements, if any, apply for national implementations. For example, if the generic DPG project uses what is commonly called a full copy-left license like the GNU Public License, a national implementation will be required to be similarly licensed. At the other end of the spectrum, most permissive licenses, like Apache, impose no restrictions on which licenses can be used for implementations, and allow also for proprietary approaches.
The Case for Clarity
Ambiguous or vague licenses are problematic because they’re open to interpretation and may cause confusion for stakeholders seeking to re-use technology, data or content. New licenses often only add to this challenge, as they are frequently developed based on bespoke use cases and purposes, and without sufficient attention to ensuring clarity and consistency in terminology.
To enable the growth of a global community of sharing, we have therefore only included licenses in the DPG Standard that have been approved by leading stakeholders in their respective domains such as OSI, Creative Commons and Open Data Commons. As a general rule, these licenses are clear and allow broad use, modification, and sharing, without onerous restrictions (refer to the full list of approved licenses).
For more information on the Digital Public Goods Alliance or the Digital Public Goods Standard, visit our website.
For specific inquiries related to licensing, please reach out to: email@example.com