Open Source Initiative Blog

Join us for OSI's first State of the Source Summit!

We need open source now, more than ever. Now is the time to foster global connections, knowledge exchange and cross-border collaboration. Only by working together can we make bigger strides in solving some of the world’s most pressing problems. The mission of OSI has always been to advocate for the benefits of open source and to build bridges among different constituencies in the open source community. Our goal is to establish State of Source as a platform to bring together open source projects, communities and advocates from around the world.

We want to thank our supporters of this event, without whom this endeavor would have been far more challenging! Our amazing sponsors for the State of the Source Summit include RedHat, Indeed, Eclipse Foundation, Bloomberg, XWiki, Zup, Bitergia, Command Prompt, Salesforce, LexPan Law, Blindside Networks/BigBlueButton, and DigitalOcean.

Please mark your calendars for September 9-11 now and visit www.opensource.org/stateofthesource to register for this exciting event!

For more information, and for the full event schedule, go to https://eventyay.com/e/8fa7fd14/sessions
Announcing OSI's New Interim General Manager

The Open Source Initiative is bringing in Deb Nicholson as its new Interim General Manager. Nicholson will be supporting the organization through a period of growth and introspection over the upcoming year as stakeholders continue building on the non-profit's past successes. She will be overseeing day-to-day operations, including marketing, staffing and infrastructure, as well as supporting board and volunteer activities.

OSI's President, Josh Simmons elaborates, "We're thrilled to welcome Deb as an Interim General Manager at OSI. Her credentials are top notch, and she's well respected within the free and open source software communities... I couldn't ask for a better partner as OSI works through its second major transformation! Deb's roots in the software freedom community and at Conservancy bode well for our movements as we strive to present a more unified front to advance our shared goals."

We would also like to take this moment to thank Patrick Masson for seven years of service as OSI's General Manager and Director. He leaves behind a powerful legacy as OSI's first full-time employee. Masson will be continuing his work as an outside consultant to support this transition as well as supporting FLOSS Desktops For Kids. We wish him all the best, both inside and outside, the open source community.

Signed,
The OSI Board of Directors
February 2020 License-Discuss Summary
In February 2020, the License-Discuss mailing list went over the following:

OSD and compulsory user reporting

Delisting of licenses

MIT-Clone and concern on the copyright notice

GDPR/CCPA and the Cryptographic Autonomy License (Beta 4)

CERN Open Hardware License 2.0

Ethical Open Source Licensing – Persona non Grata Preamble

Fairness vs Mission Objectives of the OSI

Ethical open source licensing - Dual Licensing for Justice

Discouraging governments from creating bespoke licenses

Psychological relationship between an author and the work

OSD and Compulsory User Reporting

Question whether a license would be compliant with the OSD if it would require the provision of information regarding use of the software to the author or another party.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021221.html

Answer that it wouldn’t and referenced the Desert Island test for whether people on a desert island could distribute the software among themselves.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021228.html

Delisting of Licenses

Concern that delisting would be unfair and give a bad look for the OSI.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021222.html

Suggestion for a threshold of lack of use and a deprecation period.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021223.html

Statement that licenses that lack use would mean that leaving them alone also has little impact.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021224.html

Concern regarding how the body of licenses affect the interpretation of the OSD.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021226.html

Reminder of a previous suggestion to have an “Emeritus” license list to avoid invalidation and just clarify that they are not recommended for active use.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021227.html

MIT-Clone and concern on the copyright notice

Issue with the copyright notice as it refers to the author of the initial files but not the contributors. Suggestion to replace “copyright notice” with “attribution notice” and “created by me” instead of “copyright me”.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021230.html

Suggestion to amend to add additional copyright holders as it is common to add another line below the original notice.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021231.html

Avoidance of the word “copyright” has no actual effect.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021233.html

GDPR/CCPA and the Cryptographic Autonomy License (Beta 4)

Question on which is the constitutional or statutory authority to control data used by a copyrighted or patented work of software if contractual law is solely relied on for restrictions on the use or distribution of data.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021234.html

Reference to US constitutional regulation of interstate commerce which is to congress and not the states due to complications.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021235.html

CERN Open Hardware License 2.0

Request for feedback on submitting the suite of licenses for OSI approval due to hardware and software tending to converge and much of the hardware has software elements like firmware.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021236.html

Ethical Open Source Licensing – Persona non Grata Preamble

Proposal regarding how licensing and ethical FOSS community policies can interact to discourage and shame certain potential users on the basis of morality where the community can give a statement about their values and who is not welcome. This preamble will be maintained in redistribution as it is part of the license.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021237.html

Statement that it does not belong in a license but rather in a Code of Conduct and that the addition of this into the license would make it lose its status as a Free Software license due to making it proprietary. Reference to OSD 5.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021238.html

Clarification that the proposal has no restrictions in place as only opinions of the licensor are preserved but that there is concern regarding the immortality of the preamble even if it loses relevancy.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021240.html

Concern that it may still break OSD 5 due to potential libel and defamation issues preventing developers from using code with an actionable statement to which they may be considered affiliated.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021268.html

Question on who defines who is being discouraged and shamed.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021239.html

Question on whether disclaimers will need to be made for end users.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021241.html

Answer that the licensors define who is being discouraged and shamed. Statement that end users would likely not see such a preamble in the user interface and a suggestion to have a requirement to display it. Concern that it would be easier to add names than remove old ones as anyone can add them but consensus is required to remove and that enabling the assignment for the right to relicense may be needed to prevent IP centralization.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021247.html

Suggestion for a proxy clause to be added for the delegation of the ability to update the preamble, such as a non-profit steward.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021266.html

Statement that most downstream licensees cannot be expected to update the copy of the preamble, as well as difficulties with upstream and “side-stream” copies updating their preamble.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021267.html

Concern around discrimination created by the preamble, which goes against both OSD 5 and OSD 6, regardless of permissions granted. Additional issues mentioned around the removability of the preamble if it is changeable, proliferation concerns due to multiple variations, and potentially negatively-viewed preambles.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021242.html

Statement that different treatment of different people already exists, licenses can be set to be copied freely but can’t be changed by anyone except the author, and that templates would be a practical approach.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021243.html

Clarification that propagation requires that it can’t be removed.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021250.html

Viewpoint that beliefs stated in the preamble don’t make a license noncompliant since every license that requires a notice regardless of ones own views is already forced speech. Request for information with regards to the sufficient legal risk to be considered that causes a violation against the OSD. Further statement regarding templating that OSI would approve the template and not anything else and that a versioning process should be in place.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021284.html

Statement that OSI should not be involved with social justice and that its responsibilities lies with protecting a narrow and particular set of liberties.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021312.html

Viewpoint that comparisons to software patent statements in open source licenses are irrelevant due to the preambles being directed at actions beyond the license rights to the software.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021324.html

Response that the preamble does not make software proprietary as there is no assertion of exclusive ownership rights.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021323.html

Issue that though some policy statements can be tolerated in a preamble with regards to OSD 5 and OSD 6, some may not be and go against their spirit.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021300.html

Statement that political language or advocacy should only be considered acceptable if it is to accomplish the defense or advocacy of open-source cooperation.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021313.html

Question on whether the effect of language choices in the preamble causing a group to avoid the software is essentially the same as outright prohibition against those groups.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021301.html

Reference to the similarities with badgeware licenses where the mailing list pointed out that the attribution requirements discouraged exercising the derivative work right.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021252.html

Statement on lack of legal enforceability if the new terms need to be legally enforceable.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021399.html

Question on whether discrimination against illegal activities has been tested in court, such as in the event that an open source library was a key contributor to empowering an illegal activity. Request for clarification on “the process” as stated in OSD 5.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021403.html

Answer that legal liability is on the licensee and not the licensor and that the license cannot contain a clause prohibiting use based on the licensor’s jurisdiction.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021404.html

Answer that crime is irrelevant for OSD 6 as it is relevant for law enforcement and that OSD 5 does not prevent the implementation of policies, such as with incoming pull requests.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021411.html

Fairness vs Mission Objectives of the OSI

Suggestion that licenses should be revoked if it is discovered that there was an error on the part of OSI and that it is not unfair to those who have adopted the license to do so as it is to minimize future harm.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021272.html

Agreement that licenses should be decertified if they did not meet the OSD requirements but pointed out that goals like minimizing license proliferation and redundancy are less clear-cut.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021274.html

Request for clarification if the proposal is to do a full revocation or just to deprecate and a suggestion for deprecation instead as it does not have immediate harsh consequences against its users while still discouraging future use. Further question with regards to how future license submissions would take into account precedence of revocation or deprecation of another similar license.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021277.html

Clarification that requests for deprecation by the license steward are already accepted either because it is no longer appropriate or if it has been superseded, which does not harm legacy applications. Suggestion that a process for deprecation initiated by someone who isn’t the license steward be created.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021278.html

Question on whether a review of current licenses is necessary and a suggestion for the process of doing so involving an evaluation of fixability, providing a clear explanation, multi-channel announcements, a waiting period where projects would not be allowed to use it, and a final move to a historical archive.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021296.html

Statement that projects can’t be rejected as they’re not accepted in the first place.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021297.html

Clarification on the differences between deprecating and decertification while highlighting that the latter requires a higher level of requirements.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021310.html

Recommendation to also have an affirmative effort to certify licenses even without affirmative submission.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021299.html

Suggestion to have a tag for new licenses that says “Not recommended for general use.”
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021306.html

Statement that deprecation as a first step has precedent with Intel’s request for removal of one of its open source licenses in 2005.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021327.html

Suggestion of deprecation as a first step with an understanding that it may be decertified based on further data.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021287.html

Argument that OSI is not right to assert that something isn’t open source when the term was around before the OSI and the OSD existed.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021279.html

Clarification that amending the OSD was done in the past with the addition of OSD #10 and that the OSI is not bound to always decide the current case like previous cases and changes can be made.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021281.html

Clarification that the term “open source” was not used to describe licenses before the OSI was founded.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021289.html

Ethical open source licensing - Dual Licensing for Justice

Idea around a copyleft license for software where the community would create a special exception to the license that provides greater permissiveness to all except for a specific list of entities. Questions around the compatibility with the FSD and the OSD, whether the special permission could be removed under any conditions, whether it can be expanded in other dimensions and still be FOSS, and the effect of it on copyleft as a concept.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021285.html

Question on why a single license exempting specific organizations isn’t just used instead and why it needs to be under the umbrella of open source.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021293.html

Answer that it would be an enforceable license but that it would not be FOSS and that a set of options that uphold the OSD and the FSD that allows the inclusion of other issues is necessary.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021304.html

Counter-argument that it isn’t necessary and instead counterproductive. Clarification that the OSD and FSD are set up to solve software-related problems.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021315.html

Statement that ethical license proposals are fundamentally irreconcilable with the non-discrimination values in the OSD.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021316.html

Challenge that it isn’t enforceable unless it allows or requires the exercise of the right and possibly duty to give copies of the software under the same license.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021318.html

Discouraging governments from creating bespoke licenses

Request for resources regarding the discouraging governments and similar agencies from creating bespoke licenses.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021349.html

Recommendation for Iain Mitchell’s chapter in the book Free and Open Source Software.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021351.html

Statement that all major open source licenses rely on copyright for protection, none of them have severability clauses to address what happens if one or more clauses in the license cannot be enforced, and that works authored by the US Government (USG) does not have copyright attached in the USA. Concern that if standard licenses are used, it is not known if the license will be struck completely or if only portions would be, as well as whether it would expose the government if a standard license is used when some clauses don’t apply.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021368.html

Example regarding digital editions of music in the Public Domain where information regarding the license is in the footer and the license terms in the metadata.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021376.html

Issue regarding determining the viability of creating a lawsuit as well as the costs stemming from fighting them.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021382.html

Suggestion that USG lawyers should become involved in the discussion in order to provide insight with regards to the operation of the Court of Federal Claims, the limits on private entity claims against the USG, and how the licenses propose the concerns.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021385.html

Clarification that the issue is with also protecting downstream users who may be sued for simply using the material distributed by the USG. Response that there is potentially a concern from USG lawyers regarding information provided being construed as legal advice.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021388.html

Provision of a solution to the concern where a notification is placed that legal advice is not being given, as well as that they only represent their clients and no one else reading the message and that people should consult their own attorneys, among other things.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021392.html

Correction that Mozilla 2.0 and Eclipse 2.0 both have severability clauses in Sec. 9 and Sec. 7, respectively. Issue that since open source licenses are founded upon copyright licensing, if copyright provisions are struck then there isn’t much left.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021378.html

Clarification that the concern is that the USG would need to address patents, liability, and warranty for itself and downstream users and that without a severability clause it is unclear if the non-copyright clauses would survive in court.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021381.html

Recommendation that people who write the licenses should be the ones explaining it on license-review and not proxies.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021387.html

Statement that the USG is so large that patent clauses have to be written in a way that one arm of it doesn’t inadvertently give away a patent created by another part and already licensed to another party. Suggestion that a license like CC0 with the explicit patent grant from ECL V2 exist with some broadening to the agency which the authors belong.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021362.html

Psychological relationship between the author and the work

Request for input with regards to the attachment to code developed by someone that they decide the terms under which another uses it in their solution.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021369.html

Personal interpretation that code created isn’t perceived as theirs and that code belongs to all and shouldn’t be “owned” once its Open.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021374.html

Counter interpretation that pride exists in work that is crafted while recognizing that they are “standing on the shoulders of giants” and thus publish under Copyfree terms.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021377.html

Clarification that pride and recognition are not taken away in an ownerless perspective.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021379.html

Statement that copy of one’s code remains theirs but that that the copy may or may not be the same and that there is a potential for one to consider it “our code” if modifications have been extensive but not overwhelming.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021375.html

Comment that as one becomes less afraid of what happens to the code, the desire to control goes away and possessive thinking stops.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021395.html

Statement that copyright law focuses on creative expression, which would be the implementation of the idea but that it does not protect things that are purely functional. Issues with determining creative expression on contributions depending on their significance.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021380.html

Analogy with paintings where one may paint their own work and has freedom and control as well as the risk, and comparing that with commissioned work where the painter does not have the risk but that the artist maintains a personal connection while the commissioner retains ownership.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021391.html

Clarification that this is why projects exist where the ownership is under the project and not the individual author, though they retain co-owner status.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021400.html

Viewpoint that while receiving credit is enjoyed, there is no proprietary feeling about the results of the work as the work gains more value the more it is built upon.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021405.html
License Review Process Update

We’d like to update you on some work we have underway on improving the OSI’s work on reviewing open source licenses. We’re working on two initiatives, one substantive and one process.

First, on process, we know that an email list is a suboptimal way to perform the license review process. We have published a Request for Proposals for a contractor to, first, develop a set of requirements for an appropriate license-review vehicle and, second, implement the selected process. You can find the full RFP here. If you’re interested in participating as a stakeholder, stay tuned to this space for an announcement when we’ve started work on the project itself.

Second, on substance, we are starting a License List Working Group. The mission will be to review, re-evaluate, and redefine current processes and standards for license review with a view towards ensuring that the OSI’s license list is appropriately comprehensive while also continuing to encourage the use of a smaller set of well-known, well-understood licenses. More information on the Working Group can be found here.

If you would like to participate in either initiative, contact pamela.chestek@opensource.org.

We are very excited about these two initiatives and are looking forward to broad and diverse participation in both.

Signed,
The OSI Board of Directors
OASIS Open Joins Open Source Initiative

Shared vision and combined resources extend both organizations’ ability to advance open source through standards.

PALO ALTO, Calif., June 30, 2020 -- The Open Source Initiative^® (OSI), the internationally recognized steward of the Open Source Definition and open source licenses, is excited to announce the Affiliate Membership of OASIS Open, a global nonprofit consortium managing a broad technical agenda encompassing cybersecurity, blockchain, privacy, cryptography, cloud computing, IoT, urban mobility, emergency management, and other content technologies.

“OASIS Open and OSI have been informal collaborators on licensing and other topics from the early days of the OpenDocument Format to our recent Open Projects Program,” noted Guy Martin, Executive Director of OASIS Open. “We are delighted to formalize our relationship as a sign of our mutual commitment to expanding the role of open source in the standards definition process and look forward to an exciting future for this combined open ecosystem.”

Founded in 1993, the OASIS Open community is committed to advancing work that lowers cost, improves efficiency, stimulates innovation, grows global markets, and promotes interoperability. Each project operates independently under OASIS’s industry-leading process and clear Intellectual Property Rights.

Begun in 2019, the OASIS Open Projects program provides open source communities with foundation-level support—for governance, intellectual property (IP) management, collaboration tools, outreach and events—with an optional path to standardization and de jure approval for reference in international policy and procurement. Open Projects lets communities choose from seven currently-supported, OSI-approved licenses.

OASIS Open and OSI have been consultative partners helping shape open source and open standards work in many technology domains, including ensuring that OASIS Open programs satisfy the criteria defined by OSI’s Open Standards Requirements (OSR), which mandates standards must not prohibit conforming implementations in open source software. OASIS Open also enjoys productive liaison and peer relationships with several of OSI’s other Affiliate Members.

“OASIS Open has been the most important pioneer of approaches to bridging the gap between open standards and open source, and we are excited to have a new basis on which to collaborate going forward,” said Pam Chestek, OSI Board Director and Chair, OSI Standards Committee.

The OSI Affiliate Member Program allows non-profit organizations—unequivocally independent groups with a commitment to open source—to join the OSI in support of our work to promote and protect open source software. As the steward of the Open Source Definition certifying Open Source Software Licenses, by establishing such certification as the standard for open source software development and distribution, and with the support of our Affiliate Membership, the OSI has become a cornerstone of software freedom.

About OASIS Open
One of the most respected, member-driven standards bodies in the world, OASIS Open offers projects—including open source projects—a path to standardization and de jure approval for reference in international policy and procurement. Their members include major multinational companies, SMEs, government agencies, universities, research institutions, consulting groups, and individuals are represented. Please see https://oasis-open-projects.org for more information.

About The Open Source Initiative
Founded in 1998, the Open Source Initiative (OSI) protects and promotes open source software, development and communities, championing software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition, and preventing abuse of the ideals and ethos inherent to the open source movement. The OSI is a public charity with global vision based in California. For more information about the OSI, please see https://opensource.org.