Add OSI license requriements #139
Conversation
Open source licenses are only licenses that comply with the Open Source Definition — in brief, they allow software to be freely used, modified, and shared. To be approved by the OSI, a license must go through the Open Source Initiative's license review process and as such is the industry and globally recognized standard for identifying open source software.
|
One thing to think through is how that would work with the fact that works done by government employees/owned are by default in the public domain. |
|
@ErieMeyer The Open Source Initiative (full disclosure I am the GM and a Board Director) recognizes the issues related to "public domain" as a technical term in copyright law that refers to works not under copyright — either because they were never in copyright to begin with (for example, as you mention the works were authored by U.S. government employees, on government time and as part of their job, are automatically in the public domain), or because their copyright term has finally lapsed and they have "fallen into" the public domain. To be subject to a license (open source or otherwise), a work must still be in copyright. Therefore because works in the public domain are not under copyright they cannot be licensed at all and thus should not be referred to as open source [licensed] software: there is no license. Because the documents in the playbook ("plays") refer to open source licensed work, they exclude discussions of pubic domain--again works in the public domain carry no license. If the Playbook wishes to also include works in the public domain for consideration in government sponsored contracts, development, projects, etc. that should be stated explicitly, e.g. play 05.md could state:
I believe the solution to your very valid point, would be to highlight both options are acceptable and desirable. But both options need to be defined, what is public domain and what is open source. Interestingly, many people believe assigning no license (e.g. posting work on Github publicly) makes it either open source or puts it in the public domain. As you probably know, neither is true and actually results in the most restrictive status of "all rights reserved" by the author meaning the work cannot be used without permission of the owner. I am sure the folks here don't want that. |
|
Hi @massonpj. A few quick reactions to this:
|
|
The law in the US is that government works are public domain, and the spirit of that law, to me, very much includes work the government orders to be created on their behalf. This is why our team at 18F has an open source policy to always mark our work as public domain in the US and dedicate our work abroad as CC0, and insists on the same from any contractors we work with. When 18F released its Agile Delivery Services RFQ yesterday, it includes the clause "It is GSA’s intent that any data or deliverable created as a result of a task order under this BPA be committed to the public domain." From the Open Source Initiative's FAQ on the public domain (emphasis mine):
I love the Open Source Initiative's work and role in the world, and the answer above is one I agree with fully. I don't love writing the Open Source Initiative's name into the Playbook, especially when it would discourage contractors and their procuring agencies from releasing their work into the public domain. |
|
I wholeheartedly agree with @konklone on this one. |
|
Thanks all for the comments/feedback. I'll try and respond specifically to each point.
First, the U.S. Digital Services Playbook includes language that recommends "open source" however there is no definition or criteria for "open source."
As the playbook is currently written, it appears to me any organization can label their software "open source software" and qualify for consideration. Will the authors of the Playbook, CIO.gov, and/or some other group undertake the work to determine if software considered per the recommendations of the Playbook is "open source?" What will the evaluators use to determine if any software and or license is "open source"? How will various interpretations of "open source" (and the associated requirements/affordances) be communicated and managed to all parties (those within the government and those who wish to engage with the government)? The Open Source Definition was written and is used by the OSI and the open source community when reviewing licenses to ensure that software freedom, what most people expect when evoking the term "open source," is guaranteed: use, study, modify, re/distribute. The Open Source Definition and the OSI Review Process are internationally recognized as standards that addresses the above questions and provides continuity across the industry. They are recognized by industry leaders (e.g. Adobe, Apple, Craigslist, Github, Google, HP, IBM, Microsoft, Oracle, Twitter), some of the world's most successful open source software projects and advocates (Apache, Creative Commons, Debian, Drupal, FreeBSD, Eclipse, LibreOffice, Linux, Mozilla, Wordpress, Wikimedia to name only a few) as well as the public sector (Univ. of California, Univ. of Illinois, NASA, State of California, State of Massachusetts, State of New York, U.S. Dept. of Defense, U.S. Dept. of Labor, and many others). I would point to three examples where software is labeled "open source" but, as licensed would cause significant conflicts with not only what I would assume are the expectations of those using the Playbook, but potentially with government use in any form.
The reason each of these examples should be of concern to the U.S. Government and those using the Playbook is that without an internationally recognized standard accepted throughout the sector, conflicts will occur: some based on ignorance that inhibits the very openness that this document seeks to foster, and worse, outright abuse by nefarious organizations that simply seek to benefit from the growing interest and adoption of open source software. See the recent news from Russia on this. In response to issue 3., "The OSI approval process is a best practice and enforces community norms, but is not a per se requirement." I would agree. "Open Source Software" is not defined and can be ambiguous, but "OSI Approved Open Source Licenses" and "OSI Certified" are defined and is a recognized standard. The value of including language that points to the OSI Approved Licenses is that it reduces the risk to, and overhead for, organizations seeking to comply with the U.S. Digital Services Playbook. Both government departments and agencies that seek the benefits of software freedom, as well as the companies and organizations that wish to participate, will have a clear metric and references (a list of OSI approved licenses) to assess if the software both aligns with industry norms and can inform their work when applying a license to new work. Without such a bright line to denote open source software--as you say, norms--government agencies will need to undertake the evaluation of each software license submitted, resulting in considerable overhead, possible confusion and another "standard" that they will need to refer to when developing/distributing software. While it is true that there are undoubtedly OSD-complaint licenses in use, that the OSI has not reviewed, the OSD, the OSI Approved License list and the review process, are all well established and recognized and we continue to review new licenses when submitted (e.g. our recent approval of Oracles UPL), and just as importantly guide those who seek new licenses in alternatives to avoid license proliferation. With regard to the second issue, "calling out public domain separately from open source," again I agree that there are few practical differences between CC0 and/or public domain work and permissive open source licenses and is thus, as you note, in line with the OSD. However, I would not offer the same regarding copyleft licenses as there is no way to require that modified versions/derivatives of public domain software remain CC0 or are contributed back to the public domain. One may modify public domain work and then apply a proprietary license on it (in addition they could potentially do this without modification). The OSI recognizes software released as CC0 or in the public domain (as it could be argued to be a form of "permissive" open source licenses), but we would not consider that to be open source "licensed" software. Denoting this difference would add clarity to the document for those who may not understand the differences/impact between licensing and public domain. In addition, many may not want to relinquish their copyright. I would point to the various issues reported by GIthub as evidence of confusion. Many people post code to Githib assuming that by posting it "in the public" it is either in the public domain or is open source. Neither is true and again, in US law, is actually "all rights reserved." By referencing "OSI Approved Licenses" those who want to contribute code can be assured that their work will indeed promote software freedom and be internationally recognized as open source software. We worked with Github to help develop this. The problem with, "solutions which satisfy the definition of Open Source" requires some authority to asses if that definition is met. This leads me back to my opening questions about who will do this, how will this be constantly manged, and will this create a second standard? Finally (I know, at last), I would offer that the laws around of public domain is not universal and vary across jurisdictions. Again, providing clarity can only help. |
As someone who prefers that government works, built or bought, be public domain, that's a reason for the Playbook not to define "open source" as that of an OSI-approved license.
They are free not to perform work for the government.
This is a problem, but a separate issue from what license to use. As an example, 18F's open source policy has a default A repository could also intend to license itself under an OSI-approved license, but neglect to include a visible LICENSE file or take a non-standard approach to indicating their license. This is all to say, you bring up a valid issue, it's just not something that recommending "an OSI-approved license" solves. Recommending that a license or dedication be clearly indicated in a standard way is good guidance, but I suspect is too low-level for the intent of this Playbook. In general, it's of course helpful to have definitions for things. The open source definition may be useful in that regard, whether or not it's appropriate for this Playbook. But like @vzvenyach, I still don't really like the idea of the government depending wholly on a definition maintained by a single outside entity. This neat 1998 piece by Guido Van Rossum, the creator of Python, has an interesting passage about Eric Raymond, who co-founded the Open Source Initiative:
In any case, I'll just add that I'm a devoted fan of free and open source software, have released my works under both permissive and copyleft licenses, and am glad that institutions exist to keep those definitions free and clear. I also believe public domain is the right standard to hold our public service to, and would rather see that preference made unambiguous, not discouraged by an OSI approval process or external checklist. |
|
For the record, it was nice to see the House of Representatives clear full use and participation in open source software today, and both that post and this one by OpenGov both linked to the Open Source Definition. |
|
Not to jump in (and clearly I'm so conflicted on all sides; both USDS and OSI), but I think using the OSD (at minimum) would be a wonderful idea |
|
@paultag Want to suggest language, or open a new PR with some? |
|
I've written an Open Source Policy for an Australian University, and an issue we ran into was providing guidance on which Open Source License to recommend. |
Open source licenses are only licenses that comply with the Open Source Definition — in brief, they allow software to be freely used, modified, and shared. To be approved by the OSI, a license must go through the Open Source Initiative's license review process and as such is the industry and globally recognized standard for identifying open source software.