Open Source Initiative

Subscribe to Open Source Initiative feed
Updated: 23 hours 8 min ago

February 2020 License-Discuss Summary

Mon, 2020-07-20 22:22

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

Categories: FLOSS Research

License Review Process Update

Mon, 2020-07-20 10:15

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

Categories: FLOSS Research

OASIS Open Joins Open Source Initiative

Tue, 2020-06-30 10:00
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.

Categories: FLOSS Research

Celebrating GNOME's Patent Settlement

Thu, 2020-06-11 12:00

The Open Source Initiative would like to congratulate the GNOME Foundation on its recent settlement of the patent lawsuit alleging that the Shotwell software infringed patents owned by Rothschild Patent Imaging. The settlement was a huge achievement -- not only did GNOME pay nothing, but Rothschild Patent Imaging and its owner, Leigh M. Rothschild, have agreed that, for all of their patents and future patents, they will not sue any user or developer of software under an Open Source Initiative-approved license (and their updated versions) where the software forms a material part of the infringement allegation. That is freedom from suit for the open source software world for over 100 patents.

This is a remarkable accomplishment that could only happen with the overwhelming support of the entire open source community. U.S.-based patent infringement lawsuits are notoriously expensive, so a business model has developed to sue those who appear to lack the financial means to mount a defense. The plaintiff is successful when the defendant pays a substantial sum simply because it is less than the cost to defend the lawsuit. However, with community support GNOME was able to raise over $150,000 from more than 4,000 donors, allowing it to not only stand strong against the threat but also ultimately procure a huge benefit for the open source community at large. This suit demonstrates to the world once again that the open source community and our values of mutual support, collaboration, cooperation, and transparency can accomplish greater ends than any one person standing alone.

The suit also demonstrates the critical role OSI-approved licenses play. Using an OSI-approved license demonstrates that the software project participants share common values that ultimately serve to spur innovation for the benefit of our society as a whole. Which now, thanks to the GNOME Foundation, is no longer inhibited by the threat of patent suits from the Rothschild parties. We are optimistic that more patent holders, non-practicing entities and practicing entities alike, will make the same calculation and help build instead of tear down.

Signed,
The OSI Board of Directors

Image credit: "celebrating-gnome.jpg" by Open Source Initiative, 2020, CC BY-SA 2.0, is a derivative (cropped and scaled) of "Pyro Spectaculars Marquee Event 2012, 5 March 2013" a photo by Pyro Spectaculars by Souza, available under CC BY-SA 2.0, via Flickr.

Categories: FLOSS Research

OpenJS Foundation Joins Open Source Initiative as Newest Affiliate Member

Tue, 2020-06-09 09:06

Membership emphasizes growing outreach and engagement with broader software and technology communities.

PALO ALTO, Calif., June 9, 2020 -- The Open Source Initiative® (OSI), the international authority in open source licensing, is excited to announce the affiliate membership of the OpenJS Foundation, the premier home for critical open source JavaScript projects, including Appium, Dojo, jQuery, Node.js, and webpack, and 30 more. The OpenJS membership with the OSI highlights the incredible impact of JavaScript across all industries, web technologies, communities, and, ultimately, the open source software movement.

“The OpenJS Foundation is thrilled to join OSI as an Affiliate Member and we’re proud to have Myles Borins represent our JavaScript communities, ” said Robin Ginn, OpenJS Foundation Executive Director. “In addition to all of our projects using OSI-approved licenses, our neutral organization shares common principles with the OSI, including technical governance and accountability. As an Affiliate Member, we can better advance open source development methodologies for individual open source projects and the ecosystem as a whole.”

Formed through a merger of the JS Foundation and Node.js Foundation in 2019, the OpenJS Foundation supports the healthy growth of JavaScript and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities that benefit the ecosystem as a whole. Originally developed in 1995, JavaScript is now arguably the most widely used programming language, with Github reporting it as the “Top Language” from 2014 through 2019 in their State of the Octoverse report. Javascript’s growth and popularity can be attributed to its accessibility, often identified as a language for new developers, and its applicability, a core component of today's web-driven technology landscape. JavaScript also serves as a conduit to, and proof of concept for, open source software development, projects, and communities. For some, JavaScript provides their first experience in open source development and communities, and for others, their experience in JavaScript projects and communities are helping to lead and further refine the larger open source movement itself.

The OpenJS Foundation serves as a valuable resource for both new JavaScript developers and emerging projects--offering a foundation for support and growth--as well as veterans with broad experience with mature projects--providing a platform to extend best practices and guiding principles out to the broader open source software community.

Working with the OpenJS Foundation provides the Open Source Initiative a unique opportunity to engage with one of the open source software movement’s largest and most influential communities. JavaScript developers and projects are deeply committed to open source as a development model and its ethos of co-creation through collaboration and contribution, making OpenJS Foundations affiliate membership and the community they represent a critical partnership for not only open source’s continued growth and development but the OSI as well.

 “We are thrilled to welcome aboard OpenJS as an OSI Affiliate Member, ” said Tracy Hinds, Chief Financial Officer of OSI. “It is a time in open source where it’s vital to learn from and be challenged by the growing concerns about sustainability. We look to OpenJS as a great partner in iterating over the questions to be asking in how projects are building, maintaining, and sustaining open source software.”

The OSI Affiliate Member Program, available at no-cost, allows non-profit organizations to join and support the OSI's work to promote and protect open source software. Affiliate members participate directly in the direction and development of the OSI through board elections and incubator projects that support software freedom. Membership provides a forum where open source leaders, businesses, and communities engage through member-driven initiatives to increase awareness and adoption of open source software.

About OpenJS Foundation
The OpenJS Foundation (https://openjsf.org/) is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large. The OpenJS Foundation is made up of 35 open source JavaScript projects including Appium, Dojo, jQuery, Node.js, and webpack and is supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. These members recognize the interconnected nature of the JavaScript ecosystem and the importance of providing a central home for projects which represent significant shared value.

About the Open Source Initiative
For over 20 years, the Open Source Initiative (https://opensource.org/) has worked to raise awareness and adoption of open source software, and build bridges between open source communities of practice. As a global non-profit, the OSI champions software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition (OSD), and preventing abuse of the ideals and ethos inherent to the open source movement.

 

Categories: FLOSS Research

February 2020 License-Review Summary

Mon, 2020-06-08 12:36

License-Review mailing list topics for February 2020:

  • Continued discussion on the Cryptographic Autonomy License (Beta 4)
  • Resolution of the Cryptographic Autonomy License (Beta 4) – Approved
  • Resolution on the Mulan PSL V2 - Approved

Continued discussion on the Cryptographic Autonomy License (Beta 4)

Statement for the need of consistency with capitalizations
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004649.html

Support for approval despite lingering concerns such as the potential for abuse and the earlier drafting history, due to lack of grounding in the current text. 
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004650.html

Question concerning the license and its ability to ensure that customer data won’t be locked and that the sharing of improvements to the code will be maximized
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004651.html 

Confirmation on all concerns being addressed by the license
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004652.html 

Suggestion that more discussion is still needed due to concerns with how the license is in previously-mentioned situations and how it interacts with the principles of FOSS and its effect on users, but with a slight inclination towards approval   
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004653.html

Support for rejection or further discussion due to privacy risks
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004662.html

Clarification that the license requires that users retain control of keys but that system keys are not User Data as defined 
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004663.html

Request for the location in the license for this distinction and statement that the distinction between user and system as well as client and server are unclear in peer-to-peer systems
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004664.html

Request for the location in the license for this distinction and statement that the distinction between user and system as well as client and server are unclear in peer-to-peer systems
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004664.html

Directions to section 4.1 in the definition of the source code and user autonomy provisions in 4.2.2, both where it is stated that cryptographic keys are required to make the distinction clear
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004665.html 

Concerns regarding the requirement for documentation for use, requirement for configuration information, the possibility for coercion regarding handing over encrypted data and encryption keys,  the term “recipient” being too broad, and that the issues like privacy attacks caused by the client-server style approach of the CAL. Requests for scenario examples for further discussion.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004668.html 

Clarification that there is no requirement for the generation of new documentation and that the context of configuration information is just for the information needed to install and use, that the CAL is written for a peer-to-peer application though is compatible in client-server applications, and that the term “recipient” can be used as in a peer-to-peer network users can act as a client as well as act as a server. Response that the request reflects a misunderstanding of the CAL requirements. 
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004669.html 

Request for clarification on the problems being addressed regarding user freedom, language adjustment recommendations, statement that the privacy attack is easier to accomplish, and a request for information on the limitation of the disclosure of recipient user data without the disclosure of the operator’s private data, together with an example that highlights the issue.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004672.html 

Answer that a problem addressed is the gradual re-centralization of decentralized systems, clarification that no new documentation is required and that the context is the provision of the source code, and that the example provided that highlights the issue around the disclosure of data is in the wrong layer.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004674.html 

Request for clarification whether interaction with a remote version of an application requires distribution of source code or not and modified example highlighting the issues of data accessibility and transmission and compliance with the license.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004675.html 

Statement that creating new functionalities regarding data dumps are not required by the CAL but that the license prevents removing them and that in the example there would be no violations.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004699.html 

Statement that concerns with the CAL in terms of the OSD are with regards to the forced disclosure of private data or keys, the term “use” being too broad with the suggestion to use “execute” instead, issues with the implications of data retention in the event of accidental data loss and data extraction if it is not easy, and that a peer-to-peer actor model environment would be difficult to be compliant and may result in security weakening. Sections 6 and 10 of the OSD are highlighted.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004686.html 

Clarification that there is no forced disclosure without a legal right, that the difference in wording of “use” and “execute” are not meaningful in the context of providing information, that the difficulty level of providing data has already been discussed, that there is no requirements with regards to data retention, and that liability regarding data extraction is with the service provider and no the developers.  Answer that there is no discrimination involved if the author chooses an architecture that is more difficult in terms of compliance.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004688.html 

Clarification on “user data”, statement that “use” is better, that the License Committee judged that the requirement to give user/recipient data is not too burdensome, and that OSD 6 and 10 don’t require that the license be usable for every type of software.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004692.html 

Suggestion to include the nullification of copyleft/proprietary dual licensing into the license.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004680.html 

Answer that it is not a good idea to introduce changes at this stage.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004682.html 

Recommendation to reject or have more discussions due primarily to the user data provision due to unclarity regarding who is the service provider.
 https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004679.html

Direction to section 4 which defines what providing a service is in terms of communicating the Work to another person.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004681.html 

Question with regards to a theoretical example where voice recording is submitted to improve the quality of voice recognition and the accessibility of all recordings by one user.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004683.html 

Answer that it would not allow access to the recordings of others.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004684.html 

Concerns with the PII, GDPR, CCPA, and similar laws and their implications with the CAL.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004689.html 

Answer that the CAL was written to be compatible with the GDPR and the CCPA and uses similar language.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004690.html 

Concerns with regards to the frequent occurrence that a bit of data is about more than one person and that GDPR itself is still evolving.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004705.html 

Answer that data that GDPR applies to is a different set than what the CAL considers User Data
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004708.html 

Statement that the obligations with regards to the cryptographic keys would not be under the CAL
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004696.html 

Resolution of the Cryptographic Autonomy License (Beta 4) – Approved

Approval of the Cryptographic Autonomy License (Beta 4) for the Uncategorized Licenses category
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004660.html

Eight voted in favor, none opposed, one abstained, and two were not present.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004694.html 

Resolution of the Mulan PSL V2 - Approved

Approval of the Mulan PSL V2 for the International category
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004670.html

Nine voted in favor, none opposed and abstained, and two were not present.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004695.html

Categories: FLOSS Research

State of the Source Summit

Thu, 2020-06-04 10:00

| Hold the Date | Tracks | Calls for Proposals | Additional Information | Sponsorship | Code of Conduct |

A World-wide Open Source Summit: Build your local community, while engaging the global community.

The State of the Source Summit invites open source communities of practice from around the world to organize and contribute to a global conversation on the current state of open source software: non-technical issues that foster development and community, the licenses that enable collaboration, the practices that promote contribution, and the issues confronting cooperation.

Conference Goals
  • Share the current state of open source licenses: understanding their value and impediments to further adoption.
  • Identify current, non-technical, issues affecting open source software, development, and communities through the lenses of developers, companies, and projects.
  • Conceptualize and plan for what the future may hold for open source software as a community and the Open Source Initiative as an organization.
Hold the Date (actually... hold the time zones) 
  • Start:
    • Palo Alto CA, USA, 2:00 PM PDT  (2100 UTC), Wednesday, September 9th, 2020
    • Wellington NZ, 9:00 AM NZST (2100 UTC), Thursday, September 10th, 2020
  • End:
    • Palo Alto CA, USA, 2:30 PM PDT (2130 UTC), Thursday, September 10th, 2020
    • Wellington NZ, 9:30 AM NZST (2130 UTC), Friday, September 11th, 2020
  • Location: Earth
  • Calendar and Schedule
    • Please note: this link will open a Google Calendar with a placeholder for the event days/times per your timezone. This calendar will be updated as sessions and activities are defined.
  • News and Updates
    • Please note: this link will open a Mailman subscription page, where you can sign up for email notifications.
Call for Proposals 

We hope you will consider presenting on a topic of interest and invite you to submit your presentation to the State of the Source Call for Proposals.

  • Opens, June 04, 2020
  • Closes, July 02, 2020
  • Schedule posts on August 25, 2020
Tracks 

The Open Source Initiative's mission is to educate about and advocate for the benefits of open source software and to build bridges among different constituencies in the open source community. The State of the Source serves the OSI's mission and our community, with a focus on understanding, implementing, and improving the state of open source software. Below you will find four tracks, themes that should drive each track's sessions, and even a few examples of topics that might help you develop your presentation.

Track Themes and Topic Examples  Open Source Licenses and the OSI

How do licenses and their application enable the collaboration, contributions, and co-creation realized through open source software? Understanding licenses, the motivations for their creation, their application, and affordances, and the OSI’s role, are key for successful projects, communities, and the entire open source software movement. What is (should be) the role of the OSI, the OSD, and the License Review Process? What are the challenges facing these? What does the future of licenses and licensing hold? Possible presentation topics include:

  • Benefits, risks, and possible approaches for reviewing the process and practices associated with OSI’s “License Review Process” (LRP).
  • Possible reasons and approaches for reviewing and/or editing the Open Source Definition (OSD).
  • Is license proliferation a problem and, if so, a problem that the OSI can fix?
  • Process for reviewing and potentially de-listing or deprecating approved licenses based on problematic experiences with a license that was not foreseeable at the time of approval.
  • License enforcement from community pressure to legal intervention.
  • The unwritten rules of license approval - what they are, and should they be written?
 Business & Sustainability

Open source is now used in every organization (companies, government, education, etc.). How are organizations leveraging open source licenses and software to not only deliver value to the constituents and community, but also ensure sustainability (funding, development, adoption, etc.) of the project? What are the responsibilities of those who benefit from open source software and licenses to the projects and communities that they rely on? How can we encourage, foster and support the maintainers that make it all possible? How can oganizations best engage with communities in the development of their own projects? Possible presentation topics include:

  • Business models through licensing (e.g., “Open Core”)
  • Unique issues in public and academic settings: sustainability is needed here too!
  • Source available licenses, e.g., Polyform
  • Compensation models for developers
  • Using patents to enforce OS licenses
  • Trademarks used for sustainability
 Principles, Policy, & Practices

The identification and application of open source licenses can impact both the development community and end-users. How are organizations managing their open source portfolios, identifying risks and benefits, while maximizing the value of co-development and software freedom? Possible presentation topics include:

  • License explainer, pick a license and explain it to your peers.
  • How to pick a license for your project, company, community.
  • Compliance, compatibility, re-licensing, and other issues facing adoption, use, and development.
  • "Post open source" and the emergence of ethical, source available, etc. licenses.
 “Hot Topics”

What are we missing around open source licenses and licensing, the Open Source Definition, the OSI, and other non-technical issues mpacting the open source software movement?

Additional Information  Sponsorship

The State of the Source will be a global event and provides tremendous opportunities to directly engage with the open source software community and support the work of the Open Source Initiative. We hope you will join us in our efforts to create broader awareness, increase understanding, and address issues to help educate and build bridges between open source software communities.

For more information, or to confirm your sponsorship of the State of the Source Summit, please email jenn.cummings@opensource.org.

Hosting Sponsor, $5,000 (Limit Four)

Provides the maximum exposure for your organization--both online and with local communities--while highlighting your commitment to open source software and licenses.

Benefits:

  • One branded presentation room. Includes use of company name as the room name and introduction slide promoted on screen as participants join each session.
  • $1,000 contribution, in the sponsor's name, to OSI & Brandeis University Open Source Technology Management Scholarship (https://www.brandeis.edu/gps/future-students/learn-about-our-programs/open-source-technology-management.html)
  • $500 contribution, in the sponsor's name, to support access and participation of marginalized speakers through dedicated stipends.
  • Two hallway sponsorships.
    • Includes room branding (logos, content, etc.) and 1-minute promotional deck/video (vetted) to greet participants.
  • One "locally produced" virtual BOF session (breakout-room)
  • Promotion of all "locally produced" in-person sessions. Due to concerns over the COVID19 pandemic, please ensure all local activities are in line with your local government and health regulations.
  • One session as moderator.
  • Promotion of sponsor's future virtual or in-person events.
  • Promotion and branding
    • Dedicated weekly tweet (43K followers) promoting sponsor's activity in and with the State of the Source.
      • Includes sponsor’s custom message, link, hashtags, account (runs ten weeks, beginning July 2020)
    • Recognized in OSI direct emailing promoting the State of the Source to 13,000+ contacts.
    • Logo and link included in all acknowledgments related to the State of the Source and State of the Source website.
Presenting Sponsor $3,000 (Limit Ten)

Benefits

  • One "locally produced" virtual BOF session (breakout-room)
  • $500 contribution, in the sponsor's name, to support access and participation of marginalized speakers through dedicated stipends.
  • One hallway sponsorships.
    • Includes room branding (logos, content, etc.) and 1-minute promotional deck/video (vetted) to greet participants.
  • One "locally produced" virtual BOF session (breakout-room)
  • Promotion of locally produced in-person sessions. Due to concerns over the COVID19 pandemic, please ensure all local activities are in line with your local government and health regulations.
  • Promotion and branding
    • Recognized in OSI direct emailing (13,000+ contacts)
    • Logo and link included in all acknowledgments related to the State of the Source and State of the Source website.
Captioning and Accessibility Sponsorship, $2,000 (Limit One)

Benefits

  • Named sponsor for captioning services
  • All presentations will be live captioned by a professional stenographer
  • Promotion and branding
    • One dedicated acknowledgment via Twitter (43K followers)
    • Recognized in OSI direct emailing (13,000+ contacts)
    • Logo and link included in all acknowledgments related to the State of the Source and State of the Source website.
Watch Party, $500

Benefits

  • Promotion of locally produced in-person sessions. Due to concerns around the COVID19 pandemic, please ensure all local activities are in line with your local government and health regulations.
  • $100 contribution, in the sponsor's name, to support access and participation of marginalized speakers through dedicated stipends.
  • Promotion and branding
    • Logo and link included in all acknowledgments related to the State of the Source and State of the Source website.
Code of Conduct 

All attendees, speakers, sponsors, and volunteers at State of the Source are required to agree with the following code of conduct. Organizers will enforce this code throughout the event. We are expecting cooperation from all participants to help ensure a safe environment for everybody: Be excellent to each other, show empathy, and help make this a safe space to explore ideas, share interests, and find equitable solutions.

For more information, contact jenn.cummings@opensource.org.

Quick Version

State of the Source is dedicated to providing a harassment-free experience for everyone, regardless of gender, age, sexual orientation, disability, physical appearance, body size, race, ethnicity, experience, or religion (or lack thereof). We do not tolerate harassment of State of the Source participants in any form. Sexual language and imagery is not appropriate for any State of the Source venue, including anything communicated during the content of the virtual event, on social media or any other online outlets. Summit participants violating these rules may be sanctioned or expelled from State of the Source at the discretion of State of the Source organizers, and appropriate legal action will be taken against violators where applicable.

To report any issues contact jenn.cummings@opensource.org.

Less Quick Version

Harassment includes offensive verbal comments related to gender, age, sexual orientation, disability, physical appearance, body size, race, religion, sexual images in public spaces, deliberate intimidation, stalking, following, harassing photography or recording, sustained disruption of talks or other State of the Source content, and unwelcome sexual attention.

Participants asked to stop any harassing behavior are expected to comply immediately. If a participant engages in harassing behavior, State of the Source organizers may take any action they deem appropriate, including warning the offender or expulsion from the State of the Source event and related community resources.

All State of the Source participants, including attendees, presenters, volunteers, staff, and sponsors are also subject to the anti-harassment policy.

If you are being harassed, notice that someone else is being harassed, or have any other concerns, please contact a State of the Source staff member immediately via jenn.cummings@opensource.org. Contact information for State of the Source staff will also be shared with all participants prior to and during State of the Source.

State of the Source staff will be happy to help participants contact local law enforcement or otherwise assist those experiencing harassment to feel safe for the duration of the Summit. We value your participation.

Conference Code of Conduct via Confcodeofconduct.com

 

Image credit: "StateoftheSource.png" by Open Source Initiative, 2020, Attribution 4.0 International (CC BY 4.0), is a derivative (merged, cropped, scaled, and color adjusted) of "World Grunge Map" by Nicolas Raymond, 2012, Attribution 2.0 Generic (CC BY 2.0), via Flickr; "people-man-women-grandma-grandpa-4035403" by AnnaliseArt, 2020, Pixabay License, via Pixabay, and; "browser-web-internet-technology-4026002" by jakubem, 2020 Pixabay License, via Pixabay,

Categories: FLOSS Research

Charting a Course for 2020 and Beyond

Mon, 2020-06-01 12:26

This is an interesting time for open source.

An approach to intellectual property that was once seen as radical is now mainstream. In 2011, 13 years after "open source" was coined and the Open Source Initiative was founded to promote and protect it, O'Reilly Media declared that open source had won. In 2016, WIRED followed suit. Now, open source undergirds software development across a truly unfathomable range of applications and fans the flames of other open culture movements. It has inspired new ways of collaborating with each other, experiments in community governance, and has been so successful that it is colloquially taken to mean all of the above.

And yet, open source feels so tenuous sometimes. Questions dog us. Setting aside run-of-the-mill fear, uncertainty, and doubt, people are raising legitimate questions: are our projects sustainable? Are our communities safe and healthy? Are maintainers being treated fairly? Is our work just? Can open source weather continued attempts at redefinition?

These concerns are not new, but the scale they're playing out on is. And Open Source Initiative--though it has sustained its core mission around licensing for 22 years, slogging through the legal janitorial work that makes open source adoption easy--has simply not been a leading voice in these other conversations.

Even on the topic of licensing, OSI has been found on its backfoot. Our response to the recent flare ups of open core and source available licensing was lackluster. Everyone agrees: open source needs a bolder, more responsive, and representative OSI.

How do we get there? We have a plan, and you're part of it.

A Short Take on the Long Road to Now

The key to understanding how we move forward is to first remember how we got here. OSI as we know it didn't exist until 2013. 

Founded in 1998, the organization was held together in its first decade through strong board leadership in Michael Tiemann (2001-2012) and Danese Cooper (2002-2011). Deb Bryant (2012-present), Karl Fogel (2011-2014), Mike Milinkovich (2012-2018), and Simon Phipps (2010-2020) helped OSI begin professionalizing, by hiring General Manager Patrick Masson (2013-present), and becoming more democratic, with the introduction of a community-elected board. Molly de Blanc (2016-2020), Allison Randal (2014-2019), and Stefano “Zack” Zacchiroli (2014-2017) fostered better ties with the free software community. Richard Fontana (2013-2019) elevated legal discussions, taking OSI’s licensing work from knowledgeable hackers to expert practitioners and defining a review process. And Pam Chestek (2019-present) has brought a new level of professionalism to the license review process.

This is a reductionist and inevitably incomplete view of OSI’s history, but the point is this: OSI has come a long way, and I am forever grateful to the talented and generous individuals who collectively invested decades to get us here.

Over the last seven years, OSI has: sustained its core mission, shaped policy around the globe, worked tirelessly to mitigate open washing, built an alliance of more than 125 organizations representing hundreds of thousands of people, provided a home for projects like ClearlyDefined, and rolled out programs like FLOSS Desktops for Kids and Open Source Technology Management courses with Brandeis University.

We have seen incremental progress every year. OSI has expanded its programs and refined its operations. The trouble is, our operational capacity has not kept pace with the growing responsibility.

What Comes Next

Two years ago, the OSI Board recognized the need for another transformation, and made staffing the organization a priority. Pursuing that has required us to shave a great number of yaks! Along the way, we've identified several other key changes, all of which are reflected in our Annual Initiatives and the efforts our Committees have in flight.

In broad strokes, we have deep organizational development work to do (more on that later) as well as community engagement initiatives including:

  • Create more opportunities for people to make their voices heard and get involved with the process, by convening Working Groups and Advisory Boards to work in concert with our Committees.
  • Develop a communications plan and capabilities in order to be responsive to community developments, as well as lead and facilitate emerging conversations.
  • Invest in an updated Code of Conduct and moderation tools.
  • Continue investing in documentation in service of transparency.
  • Continue targeted recruitment in service of representation.
  • Hire people to serve as Community and Communications Manager supporting this work.

Suffice it to say, we have our work cut out for us!

Well That Sounds Promising

The good news is that OSI has never been in a better position than it is now. We have all the right players on all the right bases. We're more organized than ever. And an intense period in the spotlight has brought the work we need to do into sharp focus.

The bad news is that we only have 5 months operating budget in reserve, thus lack the funding to hire additional staff... And we're likely to suffer a 20-40% drop in revenue due to the pandemic and resulting economic downturn.

Your Role In This

This is where you come in. We need your voice to make sure we plot a path forward that meets your needs, and we need your support to fund the work ahead.

We'll be sharing about new opportunities to make your voice heard as this work unfolds, but you can always reach us on social media, IRC, and directly via our mailing lists or contact form. And the OSI Board, being community-elected, is chock full of people whose job it is to serve you--you can always reach out to us individually.

If you are not yet an Individual Member, we ask you to become one, which will keep you apprised of our work and allow you to vote in our annual elections, or even nominate yourself.

If you lead a nonprofit organization or community that believes in open source, we encourage you to become an Affiliate Member, which helps us provide mutual support and allows you to nominate and vote in elections.

And if your company relies on open source to conduct business, we ask that you invest back into the community that makes your work possible by becoming a Corporate Sponsor.

Together, we'll make sure that open source continues to thrive.

With gratitude,

Josh Simmons
President
Open Source Initiative

Image credit: "charting-a-course.jpg" by Open Source Initiative, 2020, CC0 1.0 Universal (CC0 1.0) Public Domain Dedication, is a derivative (cropped and scaled) of "Compass, 11 September 2006" a photo by Adam Levine, available under CC0, via Flickr.

Categories: FLOSS Research

January 2020 License-Review Summary

Fri, 2020-05-15 13:57

License-Review mailing list topics for January 2020:

  • Continued discussion on the Mulan PSL V2
  • Continued discussion on the Cryptographic Autonomy License (Beta 4)
  • Resolution of the Vaccine License – Not Approved
  • Continued discussion on the BSD-1-Clause [Legacy]
  • Resolution of the CasperLabs Open Source License (COSL) – Considered Withdrawn

Continued discussion on the Mulan PSL V2

Suggested improvements to the text in the license in around grammar, clarity of intentions, and legal matters
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004593.html

Revised license submission
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004640.html

Continued discussion on the Cryptographic Autonomy License (Beta 4)

Questions on the license use, promulgation, and contributions
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004594.html

Issue regarding proprietary relicensing seemingly being the primary use case
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004595.html

Questions with regards to OSD compliance and user freedom, as well as further viewpoints and considerations with regards to data exportability 
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004631.html

Statement that it is OSD compliant and that arguments against it are too situation-specific
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004636.html

Resolution of the Vaccine License – Not Approved

Decision that the Vaccine License does not conform to the OSD, specifically OSD 5 regarding user discrimination, and does not assure user freedom. 
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004635.html

Continued discussion on the BSD-1-Clause [Legacy]

Argument that all that use the license should just be relicensed under the BSD License since multiple identical licenses hinders freedom due to their costs
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004637.html

Clarification that as a legacy submission, the submitter has no power over the license and that there are significant logistical issues with regards to push a change
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004638.html

Resolution of the CasperLabs Open Source License (COSL) – Considered Withdrawn

Decision that the license is considered withdrawn due to non-responsiveness and the criticisms that were brought up 
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004643.html
 

Categories: FLOSS Research

January 2020 License-Discuss Summary

Thu, 2020-05-14 20:11

License-Discuss mailing list topics for January 2020:

  • Dual Licensing
  • Copyright on APIs
  • Decision process regarding license review submissions
  • AGPL evaluation and real-world license testing
  • ZFS Kernel Code on Linux

Dual Licensing
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021191.html

Centralizing copyright licensing and not centralizing copyrights themselves 
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021192.html

Single entity open source business model
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021204.html

Copyright on APIs
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021193.html

Doubt on article assumptions due to machine-readable interface description in the source code
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021194.html

Decision process regarding license review submissions
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021195.html

Suggestion to postpone OSI evaluation of new licenses until after some time of practical use
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021199.html

The role of the OSI and defining norms
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021201.html

Writing down all rules would be divisive and further enable bad actors 
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021207.html

Postponing evaluation means ignoring and that the current OSI certification process is fine and shouldn’t be changed because of one license being reviewed. Introduce retiring licenses or have a category of "open source but not recommended."
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021203.html

It is undesirable to have the OSI determine which licenses are better than others
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021208.html

Concern with interim naming of a license while it is in use but before OSI evaluation
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021212.html

AGPL evaluation and real-world license testing
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021197.html

Copyleft-next is engaging in a public drafting process
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021198.html

ZFS Kernel Code on Linux
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021215.html
 

Categories: FLOSS Research

Work for Hire could be Limiting You, Your Company, and Open Source.

Wed, 2020-05-13 20:55

My business partner, Amanda Nystrom, and I have been operating in the Full Stack Postgres market for well over 20 years. During this time we have learned quite a few things that have positioned us as a premier service provider in North America for all things Postgres.

All companies go through phases on how to conduct business. The market is always fluctuating and as they say, “adapt or die.” In an effort to help build the professional community and the people behind the company curtain, we wanted to share a tip that has worked well for us and should be considered by all open source companies.

Do not engage as “work for hire”

As an OSI contributor and long time open source advocate, my intent is to explain why working for hire could be limiting your company and yourself. I also hope to encourage others in the community to choose a strategy of consulting or paid-for development that is beneficial to all.

What is work for hire?

“Work for hire” [1] is often misunderstood and sometimes confused with “right-to-work” or “right-to-hire” labor laws. Work for hire is specifically related to copyright law in the United States.

The United States copyright office defines work for hire as:

  • work prepared by an employee within the scope of his or her employment

Or

  • a work specially ordered or commissioned for use
    • as a contribution to a collective work,
    • as a part of a motion picture or other audiovisual work,
    • as a translation,
    • as a supplementary work,
    • as a compilation,
    • as an instructional text,
    • as a test,
    • as answer material for a test, or
    • as an atlas
  • if the parties expressly agree in a written instrument signed by them that the work shall be considered a work made for hire.

For our discussion here, we are not including work as prepared by an employee. If you are an employee, then you are compensated as an employee and the end result product is owned by your employer.

Instead, we are discussing work that is specially ordered or commissioned for use. For example, a custom script to back up a PostgreSQL database or an application to insert PDFs created by the Linux printing system CUPS into a PostgreSQL database or a recommendation document based on findings.

Confidentiality and Trade Secrets

There is nothing within this discussion that endorses sharing confidential information or trade secrets. Confidential information and trade secrets are absolutely the property of your client, whether it was your brain trust that delivered that information or not. We are only discussing a work product that is of mutual interest.

Know Your Value

Any good consultant has information that a client doesn’t have. That is why they hired the consultant; to receive expert advice on how to achieve their goals. However, that information is largely public knowledge or accessible to anyone who wishes to do the research and work themselves. However, they are hiring you because you are an expert in your field and you can achieve the results they are seeking, theoretically, at a lower cost, and more quickly, than hiring a team of employees to conduct the same work.

As a consultant where your time is your most valuable asset, you do not want to reinvent the wheel. You want and need a toolbox of utilities, tutorials, best practices, documentation, and white papers that you can easily modify to suit your next client’s needs. If you are contractually limited by “work for hire,” the previous client controls the work products and outputs that could be in your toolbox for the mutual benefit of all parties involved.

Why not work for hire?

In the simplest explanation, work for hire removes your rights as the author of original work, stopping you from reusing that work. It is antithetical to the idea of open source and to the idea of mutual good.

Essentially:

  • you may lose rights to your brain-trust,
  • you can not reuse work (even if anonymized) from one client for the benefit of another,
  • you must reinvent the wheel for similar tasks, and
  • you are essentially an employee with consultant risk and no employee benefit.

Too often consultants are taken advantage of by companies and the attorney-budget of those companies. We have seen Master Service Agreements that literally removed all rights as a consultant and made the consultant an employee without providing the benefits of employment. We have observed intellectual property clauses that assigned Prior Intellectual Property Rights to the client. The most common modification is a change of legal venue to benefit the company that resides across the country or an unwillingness to pay collection and attorney fees should the client not pay its invoices.

If you are a professional consultant or developer for open source technologies, it is imperative you consider that your business practices also support the ideals that make open source great. A fundamental value of open source is that any development work that benefits the many should not sacrifice benefits for the producers. Open source allows you to build a culture within your ideals that will bring a higher value for you, your employees, and the community at large.

1. Works Made for Hire

About the Author: Joshua D. Drake is co-founder of Command Prompt, Inc., and a long time supporter of open source, dating back to the days of the SLS Linux distribution. He is the Founder of United States PostgreSQL, a former SPI Director, an OSI Member, and a leader among the non-profit People, Postgres, Data community. The People, Postgres, Data community focuses on the professional development of People through the use of Postgres and Data.

Image credit: "WorkForHire.png" by Open Source Initiative, 2020 (CC BY-SA 3.0), is a derivative (cropped, scaled, and color adjusted) of "Barclays Cycle Hire, St. Mary Axe, Aldgate.jpg" by Colin, (CC BY-SA 3.0), via Wikimedia Commons.

Categories: FLOSS Research

Committing to Community throughout the COVID-19 Crisis

Thu, 2020-04-30 16:46

Each year the Open Source Initiative relies on the dedicated contributions of individual open source developers and advocates, OSI members, and corporate sponsors. This year, with the global pandemic now affecting so many communities, funding priorities have rightly changed: new initiatives that need dedicated support have emerged, yet many fundamental organizations still need continued support to deliver core services.

Each year the OSI attends over 20 events to meet with sponsors and secure annual funding. With so many events now canceled, our primary channel for fundraising and development has simply disappeared. We recognize many organizations may be struggling themselves and unable to contribute. Individuals too are facing unprecedented pressures, facing professional uncertainties and personal loss.

Yet in one way--perhaps small, but not insignificant--the Open Source Software movement and community is both inspired and inspiring. The Open Source Software community has come together to collaborate, contribute, and co-create to combat the COVID-19 crisis. Every day we're thrilled to discover new communities of practice emerging in response to the demands faced in combating and ultimately curing COVD-19.

  • Fabio Balli from OSI Affiliate Breathing Games was nominated by the European Union as co-curator of the EUvsVirus.org pan-European hackathon connecting civil society, innovators, partners and buyers across Europe to develop innovative solutions to overcome coronavirus-related challenges.
  • OSI Incubator Project ClearlyDefined is working with The Open Source Center at the Digital Impact Alliance to make open source tools that support relief more accessible, deployable, and interoperable. The Online Digital Global Goods catalog tracks over 200 products that support health, development, and better lives.
  • Affiliate DemocracyLab has created the COVID-19 Volunteer Platform to support at-risk families, health care workers, and first responders during the Covid-19 pandemic.
  • Affiliate Software Freedom Conservancy has shared their Remote Work Tools, to help organizations find the resources to support their distributed staff.
  • OSI members and board directors with leaders from various open source projects and organizations have created FOSS Responders to provide a crowd-sourcing approach to help those in the open source community affected by COVID-19.
  • and so much, much, much, muchmuch more...

If you have the means, and find the Open Source Software community a valuable global resource that can provide meaningful contributions to address those suffering through COVID-19, we hope you will consider donating to support a project you find inspiring.

If you believe our role here at the OSI also merits support through these challenging times, we hope you will also consider donating now.

Stay healthy, stay safe, and thank you for your support.
The OSI Board of Directors

Image credit: "COVIDCommunitiy.png" by Open Source Initiative, 2020 (CC BY 4.0)

Categories: FLOSS Research

December 2019 License-Review Summary

Tue, 2020-04-28 12:15

License-Review mailing list topics for December 2019:
- ESA Permissive PL v2.3,
- Mulan Permissive Software License v1 and v2
- LGPL-2+-KDE (Legacy)
- Cryptographic Autonomy License (Beta 4)
- CasperLabs Open Source License (COSL)
- BSD-1-Clause (Legacy)
- MIT-0

ESA Permissive PL v2.3

Concern was expressed with conflicts between the license text and its FAQ
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004450.html

Mulan Permissive Software License v1 and v2

The Mulan Permissive Software License, version 1 and version 2, were introduced.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004451.html

It was noted that this may be similar to licenses like the BSD+patents. Ambiguity in which language is authoritative.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004452.html

The authors explained that there was a need for a Chinese license to engage the Chinese developer community with Chinese version authoritative in case of conflict.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004453.html

Possible for the authority of version to be different depending on the country in use.?
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004472.html

Can the copyright holder decide which version is authoritative?
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004473.html

Two possibilities were suggested: the Chinese version be authoritative in case of legal disputes, or users select either as the normative version.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004572.html

LGPL-2+-KDE

The LGPL-2+-KDE license was submitted.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004454.html

A question asked, and confirmed: license falls outside the scope of the license review process.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004458.html

Cryptographic Autonomy License (Beta 4)

Based upon ongoing discussions with the license review committee, the author(s) withdrew Beta 3 and substituted Beta of the Cryptographic Autonomy License.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004455.html

Concerns offered regarding the effectiveness of the license, terms preventing documentation, and Interoperability.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004456.html

The lack of a patent grant and burdens placed on users for compliance was introduced.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004475.html

The importance of clarity due to uncertainty when being evaluated at court was stressed.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004506.html

Issues regarding difficulties in determining compliance were introduced and the CAL seems to be a special-purpose license only applicable to Holochain.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004509.html

A strict reading was recommended, and examples where data about a third party not be accessible on-demand were provided. It was offered that network node governance agreements were more appropriate to manage issues related to CAL than software licenses.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004523.html

Requirements that the software user provides data back to the customer even if the original software doesn’t make it available is overreaching.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004529.html

CAL has no mandatory functionality or method of compliance and instead describes what is required and having a mandatory technical structure is unwise.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004539.html

As a SaaS license, it was argued, it would not be usable by non-developers (e.g. Wordpress end-users) with compliance risks. It was offered that CAL goes against the spirit of open source software and so will continue advocating against the license.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004549.html

A suggestion was made to reject the license due to bad intentions: it would be better to focus on the license text without the classification of participants and assuming moral standards.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004564.html

Concern was voiced with the effect on downstream users.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004558.html

Clarification was offered that user data is defined as “data which the recipient has an existing right of ownership or possession” with references to the GDPR and the CCPA.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004583.html

The scope of CAL was questioned: forces apps that run on Holochain to use an open source license? Is the use of Holochain APIs, and nothing more considered distributing Modified Work?  Would social network software need to be under an open source license?
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004573.html

It was suggested that the requirement to assert patents against interoperable open source software is a fundamental flaw.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004485.html

A case was made that though any party can assert a patent, open source projects don’t assert patents and that the difference with the CAL is that the network breaks if interoperable software under other open source licenses are allowed.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004501.html

One offered that the rewording strengthened the justification of the rights of users to their own data in terms of exercising user freedom, however, may be too narrow.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004463.html

CasperLabs Open Source License (COSL)

https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004508.html

The initial comment was that the license is not a good candidate for approval due to focus on a business model,  complexity without good reason, onerous obligations to the licensor, specific to distributed ledger technology, unstable links, ceding decision power to the licensor, clashes with OSDs 6, 8, and 10, that OSD 3 is not fully fulfilled.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004513.html

It was offered that the terms in the license are more appropriate for governance agreements, not software licenses.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004527.html

A question was posed on why GPLv3, AGPL, or the CAL are insufficient for the purposes of COSL?
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004521.html

It was suggested the license violates OSD 5, 6, 7, and 9.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004530.html

As many people stated issues are unpassable it was proposed further discussion was no longer needed.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004533.html

A comment was made that the license privileges one set of contributors over others and allows expropriation.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004532.html

BSD-1-Clause

The BSD-1-Clause license was submitted for approval.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004510.html

This was identified as an obvious case for approval.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004518.html

MIT-0

The approval status of MIT-0 license was requested.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004576.html

An observation was made that the notation on the SPDX list may be inadvertent, noting originally listed as “not OSI-approved.”
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004578.html

Recognition was made that the license author/steward is not claiming it is OSI-approved.
https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004579.html.

Note

If you'd like to participate on the lists, head over to https://opensource.org/lists for information on how to subscribe.

Categories: FLOSS Research

December 2019 License-Discuss Summary

Tue, 2020-04-28 11:35

License-Discuss mailing list topics for December 2019

  • the relevance of FRAND (fair, reasonable, and non-discriminatory) in the context of mobile communication standards, and
  • combining LGPL and MIT licenses under a single LGPL-licensed release.
FRAND (Fair, Reasonable, and Non-Discriminatory) Relevancy

Lawrence Rosen references a decision by the US Court of Appeals for the Federal Circuit (CAFC) involving the use of FRAND in utilizing patents around mobile communications standards and argues that FRAND fails in its attempt to bring logic to the process. Rosen also argues, based on feedback from a patent attorney, that it then significantly increases litigation costs.

License Use Inquiry

Marios Constantinou asks about whether it is possible to release software containing components released under the MIT license and the LGPL all together under a LGPL.

Philippe Ombredanne confirms that it is possible.

Note

If you'd like to participate on the lists, head over to https://opensource.org/lists for information on how to subscribe.

Categories: FLOSS Research

Using Open Source Tools To Fight COVID-19

Mon, 2020-04-20 08:37

As we all adjust to living with the new realities that COVID-19 has brought, we are reminded how fragile our world can be. However, many open source tools and technologies have been developed that are being used to fight this crisis around the world. Two of these tools are:

  • SORMAS (the Surveillance Outbreak Response Management and Analysis System) was designed to track and manage the Ebola outbreak in West Africa. It has been adapted for use by organizations to track and manage COVID-19 cases
  • DHIS2 is a health tracking system that is used around the world. The DHIS2 team has released a new package to accelerate case detection, situation reporting, active surveillance and response for COVID-19

The Open Source Center at the Digital Impact Alliance (OSC at DIAL) was created to strengthen the open source ecosystem and provide support to digital platforms like SORMAS and DHIS2 that have been developed to address the Sustainable Development Goals (SDGs).

For years, global health experts have been saying that another pandemic with the speed and severity to rival those of the 1918 influenza epidemic was a matter not of if but of when. Factors like climate change only increase the risks of new outbreaks around the world as vector-borne diseases move to new areas. Sadly, when a health crisis like this arises, it is usually the most impoverished communities that are impacted most, because resources are scarce and fewer systems exist to support the most vulnerable.

Technology has an important role to play in supporting better health in low-and-middle-income countries (LMICs). As we see with SORMAS and DHIS2, organizations have responded to these new risks by developing technologies that give people tools and data to fight outbreaks like COVID-19. OSC has also provided direct support to other platforms like Medic Mobile, Ushahidi, and Open Street Map that have been deployed to support COVID-19 response. Beyond health, we have also seen how technology platforms can positively impact lives through remote learning, mobile payments, and messaging applications.

The OSC is working to make open source tools more accessible, deployable, and interoperable. To that end, DIAL has created their Online Digital Global Goods catalog (currently a beta product). This tool tracks over 200 products that support health, development, and better lives. Sadly, many of these products are not well known and not used as effectively as they might be.

Having the ability to quickly discover and evaluate available digital public goods will make a significant difference when handling the response to a communicable disease pandemic. The difference between being in the containment or mitigation phase of an outbreak relies on the ability to find an existing tool like a disease surveillance system or knowledge management system, all in one place. For example, OpenMRS, one of the products in the online catalog, was customized into two separate Ebola EMR servers during the height of the Ebola crisis. Using the same approach, OpenMRS could have the potential to be used in managing the COVID-19 cases.

In addition to providing a list of products, DIAL is working to provide relevant data about these products to help potential users evaluate them. DIAL is working with ClearlyDefined to collect fact-based data about the digital technologies in our catalog.

ClearlyDefined was designed to provide license data for open source projects in a clear, consistent way that gives open source consumers and producers confidence. It gets open source components’ license, source location, and copyright information in an automated, transparent way, and then produces data as a service to its users. In cases where the license information is missing or ambiguous, members of the community are able to discuss and submit changes that will improve the data. All changes to the ClearlyDefined data are upstreamed back to the original projects in order to have future versions of the components be more “clearly defined”. Over time, the project hopes to help all of the open source ecosystem become more clear in its license data.

DIAL is leveraging the work done by ClearlyDefined to show information about the licenses that digital technologies have been developed under. DIAL and ClearlyDefined are also working to expand the data that we can provide through the ClearlyDefined platform - including security and vulnerability information.

It’s DIAL’s goal to provide comprehensive information about the quality and sustainability of products that will allow users to understand and evaluate these digital tools so that they can deploy them effectively to improve the lives of people around the world.

If you’re interested in learning more, visit the DIAL Online Catalog or ClearlyDefined.

Image credit: "COVID19.png" by Open Source Initiative, 2020 (CC BY 2.0), is a derivative (cropped, scaled, and color adjusted) of "Novel Coronavirus SARS-CoV-2 (49584358682).jpg" by National Institute of Allergy and Infectious Diseases (NIAID), (CC BY 2.0), via Wikimedia Commons.

Categories: FLOSS Research

Your Course to Open Source

Fri, 2020-04-17 17:17

We're adding to our fully-online Open Source Technology Management courses to provide those pursuing a career around open source software even more options. In addition to our fully accredited, credit-barring courses offered through Brandeis University, we've developed six new "micro-courses." Taking just four weeks and guided by high-profile leaders in the open source community, you'll have the opportunity to explore the latest trends and techniques driving open source projects and companies. Case studies highlight real-world scenarios and solutions impacting the creation and delivery of open source software across industries. Group projects provide virtual teams direct experience in the highly collaborative, iterative, and innovative world of open source communities of practice.

And of course, just like our traditional courses, OSI members receive a 15% discount off the cost of our new micro-courses.

The goal of these courses, and why the OSI is so interested in supporting them, is to prepare the next generation of project founders, entrepreneurs, and business leaders to understand, leverage, and succeed as authentic open source users, developers, contributors, and maintainers.

Our micro-courses cover everything those working with open source software and communities need to know with four options that give students just the right credential to realize their educational and career goals.

Micro-courses:

  • Cultivate an Open Source Community (begins on June 1, 2020)
  • Integrate the Open Source Community (launches July 6, 2020)
  • Open Source Business Practices
  • Establish an Open Source Program Office
  • Open Source Workflow and Infrastructure
  • Production of Distributed Open Source Software

Credential options

  • Option 1: Take a single 4-week micro-course. Zero in on specific skills and knowledge to round out your professional profile. Our two upcoming courses are, Cultivate an Open Source Community (beginning on June 1, 2020) and Integrate the Open Source Community (launching July 6, 2020).
  • Option 2: Complete two micro-courses in a given topic area, and earn a digital badge in one of these three areas:
    • The Business of Open Source,
    • Open Source Community Development, or
    • Open Source Development Fundamentals.
  • Option 3: Complete all six micro-courses, and receive a certificate in Open Source Technology Management. Show your employer you're serious about open source, and now they can be too.
  • Option 4: Complete a capstone assignment at the conclusion of two micro-courses, and earn 3 graduate-level credits. Add open source software to your graduate experience.

Sign up to receive more information about the program. If you have specific questions, please email Kathryn Wight at kwight@brandeis.edu.

Image credit: "OpenCourse.png" by Open Source Initiative, 2020, CC0 1.0 Universal (CC0 1.0) Public Domain Dedication, is a derivative (cropped, scaled, and color adjusted) of "learn-3653430_960_720.jpg" by geralt (Pixabay License), via Pixabay.

Categories: FLOSS Research