Open Source Initiative

Subscribe to Open Source Initiative feed
Updated: 4 hours 20 min ago

Juniper Networks Extends Commitment to Open Source Software and Communities through Open Source Initiative Sponsorship.

Sun, 2019-07-14 13:52

Generous support from long-standing open source collaborator and contributor will advance open source alignment and foster open standards.

OSCON, Portland, OR - July 15, 2019 – The Open Source Initiative ® (OSI), the founding organization of the Open Source Software movement and steward of the Open Source Definition, announced today corporate sponsorship by Juniper Networks, the longstanding proponent of open source software and open standards, and industry leader in automated, scalable, and secure networks. Juniper Networks firmly believes open source and open standards foster greater innovation, and for years has actively participated in a variety of open source communities and key standards bodies, including FreeBSD Foundation, Linux Foundation, Cloud Native Computing Foundation, and OpenStack Foundation. In addition to their support of open source foundations, the networking company has released or contributed to many free and open source projects such as OpenStack, Ansible, Salt, PyEZ, wistar, OpenNTI, Tungsten Fabric, along with dozens of others.

“Open source has never been more fundamental to technology innovation today, forming the building blocks for widely used platforms in networks, clouds and applications in every industry sector.” said Randy Bias, VP of Technology and Open Source Software. “Juniper supports the OSI’s key role in articulating and defending the principles on which open source is based, especially as the technologies in which open source is used rapidly evolve and respond to competitive and regulatory pressures.”

“Open source has meaning,” added VM (Vicky) Brasseur, Director of Open Source Strategy at Juniper Networks. “It means a lot to Juniper Networks, which recognises the benefits it receives from using Open Source Software and its responsibilities to the communities that build that software. That meaning extends beyond the software to the term itself, as represented in the Open Source Definition (OSD). Without this shared and standard definition, Juniper and other enterprises could not communicate and operate effectively. We at Juniper are grateful for the dedication that OSI has shown over the past and future years to protecting the Open Source Definition and the meaning of open source.”

As more and more companies shift from being consumers of open source to contributors—or even creators—of open source, many face internal challenges: executive buy-in, re-orienting middle management, re-engineering internal processes, and identifying compatible business models that don’t just work with open source (or conflict with it), but actually leverage its power to innovate and differentiate. These are the issues now front and center for so many seeking the benefits and successes of Open Source Software, and this is exactly where the OSI is focusing work today: continuing efforts in awareness and adoption, while expanding work to promote authenticity and foster sustainability.

Support from the world’s leading technology companies, like Juniper Networks, is critical for not only the financial contributions that keep OSI operational, but also for their role as exemplars who help to inform current practice and mentor the broader Open Source Software community. “Juniper have been tremendous support to OSI while we have been establishing the Open Source and Standards Working Group to address the challenges faced understanding open source by the de jure standards community” said Simon Phipps, OSI Director and immediate past President. “Having them additionally offer sponsorship is most welcome and we look forward to further collaboration.”

About Juniper Networks
Juniper Networks simplifies the complexities of networking with products, solutions and services in the cloud era to transform the way we connect, work and live. We remove the traditional constraints of networking to enable our customers and partners to deliver automated, scalable and secure networks that connect the world. Additional information can be found at Juniper Networks (www.juniper.net) or connect with Juniper on Twitter, LinkedIn and Facebook. Discover more about Juniper Networks and open source, at https://www.juniper.net/us/en/company/open-source/.

About The Open Source Initiative
Founded in 1998, The Open Source Initiative 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 and sponsorship opportunities, please see, https://opensource.org/sponsors, or connect via Twitter.

 

Categories: FLOSS Research

On Why OpenStack Foundation Joined the OSI

Wed, 2019-07-03 12:35

Over the past year, the definition of open source has been challenged, as some companies wanted to change the licensing of their software while continuing to reap the benefits of calling it open source, or at least the benefits of being potentially confused with open source.

That makes the work of the Open Source Initiative more important than ever. For more than 20 years, the OSI has been a steadfast guardian of the Open Source Definition. They’ve kept it focused on user freedoms, evaluating new proposed software licenses against that definition, while discouraging further license proliferation. They’ve also been instrumental to the success of open source through their tireless advocacy and education work.

These objectives resonate with the work we do at the OpenStack Foundation (OSF). Today open source is necessary, but not sufficient: users of open-source licensed software are sometimes denied some of the original free and open source software benefits. We need to go beyond how the software is licensed and drive new standards on how open source should be built. Users should be able to tell easily the difference between a truly open collaboration guaranteeing all of open source benefits and single-vendor or open core projects.

“Without this single, standard definition of [the kilogram] or other fundamental units, commerce as we know it would not be possible. There is no trust in a world where anyone can invent their own definition for units, items, and concepts on which others rely, and without trust there is no community, no collaboration, and no cultural or technological development,” OSI, affirmation of open source definition.

This work cannot happen unless we base it on a strong and steady open source definition, focused on user freedoms. That’s why two months ago the OpenStack Foundation joined other open source organizations in signing the affirmation of the open source definition. That’s also why today the OSF is joining the Open Source Initiative as an affiliate member.

I’m looking forward to working closer with the OSI on those critical topics, and discuss challenges in the future of Open Source with them.

About the author

Thierry Carrez is the vice-president of engineering at OSI Affiliate OpenStack Foundation and an OpenStack Technical Committee elected member. A long-time advocate of free and open source software and Python Software Foundation fellow, he was previously involved with Ubuntu server and Gentoo Linux security.

Image credit: "CarrezBlog.png" is a derivative of "Locusts and wild flowers", by Jonathan O'Donnell , via Flickr, and used with permission under the Creative Commons Attribution 2.0 Generic (CC BY 2.0) license.

This article was originally published in Superuser

Categories: FLOSS Research

Open Source Initiative Welcomes TODO Group as Affiliate Member

Mon, 2019-07-01 12:14

PALO ALTO, Calif. - July 2, 2019 -- The Open Source Initiative ® (OSI), the non-profit corporation with global scope formed to educate about and advocate for the benefits of open source and to build bridges among different constituencies in the open source community, announced today the affiliate membership of TODO Group. Boasting membership from some of today's most active corporations working in and with Open Source Software, the TODO Group shares experiences, develops best practices, and collaborates around common tooling to address some of the most common challenges related to open source program management, development, deployment, and management.

As Open Source Software continues its growth into and across corporate infrastructure, more and more companies are seeking peers and partners to help understand, not only "the value of open source" but "the open source ethos" as well. Businesses across industries--not just technology--use, contribute to, and maintain, thousands of open source projects, both large and small. Despite open source's twenty year history, many of these programs face challenges in ensuring high-quality and frequent releases, engaging with developer communities, and contributing back to other projects effectively. Here, as a resource to those seeking authentic engagement with open source communities of practice, the OSI and TODO Group will work together, helping organizations identify potential projects, assess community alignment, and participate credibly and reliably to foster success.

"TODO Group wants to join as an affiliate to support the mission of the OSI which we believe is a critical organization protecting the values of the open source community." says TODO Group co-founder, Chris Aniszczyk

Of particular note are, The Open Source Guides, developed by the TODO Group in collaboration with The Linux Foundation (also an OSI Affiliate Member), and the larger open source community. The Guides collect best practices from the leading companies engaged in open source development, and aim to help organizations successfully implement and run an open source program office. The OSI and TODO Group expect these guides to be living documents that evolve via community contributions. The TODO Group also runs the official open source program management survey every year.

"OSI is excited about the work TODO Group is doing, especially with its guides. They're paving the way for companies to more fully realize the value of Open Source Software, both for the business and for the end user," said OSI Vice President, Josh Simmons.

The OSI Affiliate Member Program is available at no-cost to nonprofits, educational institutions, and government agencies that support the OSI's mission 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 TODO Group
TODO: talk openly, develop openly. The TODO Group members believe they will improve their open source programs - and their contributions to the open source movement as a whole - by working together. TODO is specifically intended as a forum for companies' open source program managers to come together. Members generally tend to represent companies who consider open source to be an adjunct their core business. To learn more about the TODO Group, visit, todogroup.org.

About The Open Source Initiative
Founded in 1998, The Open Source Initiative 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, opensource.org.

Categories: FLOSS Research

Publication of Research on Company Contributions to OSS Projects

Sun, 2019-06-30 16:25

IEEE Transactions on Software Engineering has published an article on company contributions to community open source projects authored by partners in the LIM-IT project.

"On Company Contributions to Community OSS Projects" reports an investigation of how practitioners working for businesses interact with eight community OSS projects of various sizes in diverse domains, including cloud computing and the internet of things. The article also investigates why contributors working for companies use particular ways of working to achieve the strategic aims of the businesses that commission their work.

Through analysis of interviews with practitioners, the article provides insights into how individuals working on behalf of companies can and do interact with projects, and the motivations for their actions arising from business and technical pressures. Factors influencing contributor work practices can be complex and are often dynamic and include considerations such as company and project structure, as well as technical concerns and business strategies.

For example, interviewees reported the value of using mailing list questions to send signals to multiple audiences, including the core developers and their own clients. Other interviewees described the challenges of delivering business products and services that depend on software from the OSS projects investigated, and how those challenges can motivate approaches to the company's software development process that may involve additional work in the short term, but are expected to bring long-term benefits to the business.

The article also describes the motivations of some businesses that contribute to OSS projects in ways that intended to support the project itself rather than just making technical contributions such as implementing new features and fixing bugs. In most such cases, interviewees reported that the OSS project was a significant component of a company product, and, in a few cases, critical to the business. Company contributions aimed at sustaining the OSS project, often made through core developers employed by the business, included nurturing new contributors and improving software quality, and have the benefit of supporting the long term aims of the business.

The article is published as open access.

The LIM-IT Project
The LIM-IT project is a collaborative research project between eight Swedish companies and the Software Systems Research Group at the University of Skövde. The project is financially supported by the Swedish Knowledge Foundation. The overarching goal of LIM-IT is to develop, use, and scrutinise effective work practices and strategies for the development, procurement, and organisational implementation of software systems in a number of complex application domains, where such software systems with associated digital assets typically involve several open source projects (as well as proprietary software).

Submitted by,
Simon Butler, School of Informatics, University of Skövde, Sweden
Björn Lundell, Software Systems Research Group, University of Skövde, Sweden & OSI Affiliate Member, Open Source Sweden

Image credit: "PubCompanyContribsOSSP.png" is a derivative of "BUSINESS_cubestalk.png", via OpenSource.com, and used with permission under a Creative Commons with Attribution (CC-BY-SA) license.

Categories: FLOSS Research

OpenStack Foundation Joins Open Source Initiative as Affiliate Member

Wed, 2019-06-26 21:12

Membership affirms open source community's support of the Open Source Definition and OSI's mission as steward.

PALO ALTO, Calif. - June 26, 2019 -- The Open Source Initiative ® (OSI), steward of the Open Source Definition and internationally recognized body for approving Open Source Software licenses, today announces the affiliate membership of The OpenStack Foundation (OSF).

Since 2012, the OSF has been the home for the OpenStack cloud software project, working to promote the global development, distribution and adoption of open infrastructure. Today, with five active projects and more than 100,000 community members from 187 countries, the OSF is recognized across industries as both a leader in open source development and an exemplar in open source practices.

The affiliate membership provides both organizations a unique opportunity to work together to identify and share resources that foster community and facilitate collaboration to support the awareness and integration of open source technologies. While Open Source Software is now embraced and often touted by organizations large and small, for many just engaging with the community—and even some longtime participants—challenges remain. Community-based support and resources remain vital, ensuring those new to the ecosystem understand the norms and expectations, while those seeking to differentiate themselves remain authentically engaged. The combined efforts of the OSI and the OSF will compliment one another and contribute to these efforts.

"For more than 20 years, the Open Source Initiative has been instrumental to the success of open source through their tireless advocacy and education work, and as the steadfast guardian of the Open Source Definition: focused on user freedoms, evaluating new proposed software licenses against that definition, while discouraging further license proliferation," said OSF VP of Engineering, Thierry Carrez.

"The broad support of our work in promoting and protecting Open Source Software and the specific endorsement of the Open Source Definition is critical for not only the OSI as an organization, but also for the users, developers, and communities who rely on a common set of principles and a shared ethos," said OSI General Manager, Patrick Masson. "The OpenStack Foundation's decision to join now as an Affiliate Member, just as we are seeing some try to manipulate community norms, is extremely gratifying and makes a clear statement. We thank them for their voice."

"Over the past year, the definition of open source has been challenged, as some companies wanted to change the licensing of their software while continuing to reap the benefits of calling it open source, or at least the benefits of being potentially confused with open source, Carrez added. "That makes the work of the OSI more important than ever. The objectives of the OSI resonate with the work we do at the OSF. Today open source is necessary, but not sufficient: users of open-source licensed software are sometimes denied some of the original Free and Open Source Software benefits. Users should be able to tell the difference between a truly open collaboration guaranteeing all of open source benefits and single-vendor or open core projects."

The OSI Affiliate Member Program allows any non-profit organization, educational institution, user community, or government agency—unequivocally independent groups with a clear commitment to open source—to join the OSI in support of our mission 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 Affiliate Member Program was developed to extend the reach of both the OSI and each participating member through community, collaboration, and co-creation. The program provides a platform to identify, communicate, and address issues important to furthering open source awareness and adoption, whether those initiatives are begun by the Affiliate, the OSI, or emerge from the Open Source Software community.

About The OpenStack Foundation
The OpenStack Foundation (OSF) supports the development and adoption of open infrastructure globally, across a community of nearly 100,000 individuals in 190+ countries, by hosting open source projects and communities of practice, including datacenter cloud, edge computing, network functions virtualization (NFV), CI/CD and container infrastructure. To learn more about the OSF, visit: https://osf.dev

About The Open Source Initiative
Founded in 1998, the Open Source Initiative 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

CAVO encouraged by—and encouraging—state and local governments’ open source elections systems.

Wed, 2019-06-12 10:23

OSI Affiliate Member, California Association of Voting Officials (CAVO) is reporting significant developments to advance the use of Open Source Software within electronic voting systems.

According to CAVO, the PAVE Act, tendered by United States’ senators Ron Wyden of Oregon and Kamala Harris of California, includes provisions to address financial barriers that could be incurred by state and local governments evaluating open source options for their elections systems.

CAVO communications director Brent Turner explained, the PAVE bill sets a variety of cybersecurity standards, and requires every voting machine used by a state or local government to undergo testing to affirm those requirements are met. In addition to the standards set forth in PAVE, The Department of Homeland Security (DHS) also has their own requirements. PAVE directs DHS to undertake this testing, of both the standards included in PAVE and their own, on behalf of the state or local government.

Turner added, “Local and state governments are of course also free to set their own additional cybersecurity standards for voting machines used in their jurisdictions beyond those identified in PAVE and by DHS”. Section 2216 of the PAVE bill states that DHS will cover the costs to test any open source technology against state or local voting standards. Turner noted this is critical for the adoption of open source options as “proprietary providers of voting technology can easily foot the bill themselves to have their product tested for compliance with those state or local standards, but open source projects may not have the resources to fund the certification process, thus eliminating themselves from consideration by state and local jurisdictions.”

“In essence, the PAVE bill makes it easier for state and local governments to use open source technology, or, at least, to make sure the cost of certification doesn’t get in the way.”

Open source voting pioneers Brian Fox and Alan Dechert have been working on open source solutions since Dechert’s first public demonstration of an open source election system in 2004. Congresswoman Tulsi Gabbard, representing the 2nd District of Hawaii, was the first to include Open Source Software in federal legislation (H.R.5147), what Fox said at the time would, “give appropriate security direction to the nation's election officials. Congresswoman Gabbard is appreciated as a pioneer advocating the science of protecting our democracy."

CAVO expects such federal legislation to help expedite the development of open source voting systems in California, which can then serve as a model for other states. Turner emphasized, “We have been working on this for almost 20 years. We must now make sure that California Governor Newsom and Secretary of State Padilla understand that if we are to have safe and secure elections in the United States, we must immediately transition from the proprietary software model to a GPL licensed open source system.”

The state of New Hampshire, the city of San Francisco, and the United States' largest voting jurisdiction, Los Angeles, recently announced their intentions to deploy open source voting systems. In addition, the California Assembly recently passed CA AB 1784, which provides "matching funds" for counties developing open source voting systems. The bill, according to CAVO, is expected to make it through the Senate and be presented to Governor Newsom for signature.

Categories: FLOSS Research

Knowage Renews Sponsorship in Support of Open Source and Open Source Initiative

Thu, 2019-06-06 10:46

Open Source Software project cultivates collaboration by extending outreach to OSI as part of broader community development.

Knowage, the open source suite for modern Business Analytics, combining traditional and big data sources into valuable and meaningful information, has renewed their sponsorship of the the Open Source Initiative® (OSI).  Knowage (formerly SpagoBI) has a 14-years history of open source collaboration, where individuals and companies work together to meet the latest analytical needs, including collaboration with current OSI Affiliate Members Eclipse Foundation, OW2, and Engineering Group- one of the world's leading specialist providers of services, software development and digital platforms that support both public and private companies or organizations through digital transformation.

Powered by a strong international open source community, and released under AGPL3, Knowage code is freely accessible on GitHub.

For over twenty years, the OSI has worked to raise awareness and adoption of Open Source Software, and build bridges between communities. Support from organizations like Knowage, not only provides the OSI with critical financial resources for continued operations, but even more valuably, extends the OSI's network exponentially through Knowage Labs' multiple international partners and collaborators.

"Knowage proudly supports the OSI's efforts in promoting open source to drive innovation, and shares their goal of promoting growth and contributions through authentic engagement across international communities," said Grazia Cazzin, Knowage Director.

"Knowage highlights how businesses, foundations, and projects can come together to co-create innovative open source software and healthy communities," said Patrick Masson, General Manager of the Open Source Initiative. "Maintaining an open ethos that ensures community success, not just one project's, is exactly how open source should work, and we thank Knowage for their commitment."

As a non-profit, community-driven organization, the OSI relies on the support of volunteers who lend their time to develop and manage internal operations and working groups; individual contributing members, whose annual dues provide critical support and whose votes elect the Board; Affiliate Members, composed of a who's who of open source projects and foundations, and; corporations who choose to support our mission through in-kind donations and generous financial contributions.

About Knowage Labs
Knowage Labs, together with the open source community, develop Knowage Business Analytics software, manage related professional services, and coordinate a network of international affiliates that serve as local contact points for customers and integrators. Knowage Labs professionals are employed by Engineering Group with offices in Italy (Bologna, Milan, Rome, Padua, Turin) and Republic of Serbia (Belgrade). For more information, see the Knowage Community Edition.

About 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

May 2019 License-Review Summary

Mon, 2019-06-03 18:21

In May, the License-Review mailing list saw extensive debate on the Cryptographic Autonomy License. The list also discussed a BSD variant used by the Lawrence Berkeley National Laboratory, and the Master-Console license.

The corresponding License-Discuss summary is online at https://opensource.org/LicenseDiscuss052019 and covers an announcement regarding the role of the License-Review list, discussion on the comprehensiveness of the approved license list, and other topics.

Cryptographic Autonomy License

The review of the Cryptographic Autonomy License (CAL) continues. Back in April, Van Lindberg submitted the CAL as a network copyleft license, but with broader scope than the AGPL (see the summary).

While the CAL clearly tries to comply with the OSD, there are widespread concerns as to whether some fundamental aspects are compatible with open source and software freedom.

Public Performance

Bruce Perens claims that use of public performance rights implies a field-specific restriction in the sense of OSD #6, e.g. because it would allow private use but not public use. (Note: the mere use of these rights does not create such a restriction.)

Scott Peterson [1,2] argues that software interoperation cannot be a “performance” in the sense of US copyright law – even if a public performance right exists for software. The CAL makes software interoperation more difficult and should not be approved. Van Lindberg provides his analysis of the term. Notably, Lindberg's definition does not require a human audience for the performance.

Chestek [1,2] finds a potential problem with how public performance interacts with modified works, as parts of the license only consider public performance of interfaces. Van Lindberg appreciates this point.

User Data

Bruce Perens argues that the CAL's user data provisions go beyond copyright law. Users don't have an a priori right to receive their user data until the CAL created this right. But this means that the operator's copyright license is conditional on fulfilling the user data obligations, which is an unreasonably far-reaching compulsion.

Pamela Chestek follows up on April's discussion on whether the CAL's user data clause is comparable with the GPLv3's anti-Tivoization clause. Van Lindberg sees a distinction between two of CAL's clauses: The CAL forbids locking down the software via cryptographic means, a kind of Tivoization. The CAL also requires user data to be provided, which is necessary to ensure user freedom in a SaaS context. Bruce Perens agrees that this should be fixed – but by some law, not by a license. And anyway, the user should just keep backups of their data.

Nigel Tzeng [1,2,3] thinks the user data obligations are unrealistic and excessive, for example where the operator has no easy way to make a copy of the data. This is problematic even with a good faith effort to comply, and makes the CAL “unworkable for most operators.” How detailed do requests have to be? Does holding a copyright license imply a possessory interest? But if the user data only covers the user's inputs (not modified or intermediate formats), the right to a copy is also not very useful.

Van Lindberg [1,2,3] responds that the user data clauses ensure data portability to inputs and outputs of the software, and where the user has some possessory interest in the data. What that encompasses precisely would depend on the jurisdiction. Having a (public) license for some data does not imply a possessory interest.

User data requests will typically only cover data that the end user uploaded. This can be implemented via export functionality in the software (note: as is already common in GDPR-compliant systems). That does not imply excessive effort for the operator. Where no such functionality is implemented this may require some effort, but that is comparable with having to provide the source code. When the request covers data that they didn't upload, they would have to specifically demonstrate their possessory interest.

Bruce Perens [1,2] doesn't buy Lindberg's argument that providing user data were easy. In a blockchain setting, providing user data might be as simple as providing a copy of the blockchain. But in other settings operators have no guidance or guarantees. Peer to peer applications seem especially problematic, since every end user would be an operator. Lindberg's fixation on certain SaaS settings is not helpful.

GDPR

Chestek [1,2] assumes the GDPR is being referenced because there would otherwise be a conflict with CAL compliance. Such preferential treatment of the GDPR would be “facially non-compliant with OSD 6”: it relieves someone complying with the GDPR from complying with the CAL. Compliance with the CAL might also be impossible if a jurisdiction has conflicting privacy laws. The section should be rephrased to avoid being specific to any legal regime, or removed when no conflict is expected.

Lindberg [1,2,3] explains that the reference to GDPR is intended to streamline compliance: if the operator already complies with the GDPR, that's already good enough for compliance with the CAL's user data requirements. This is just an interpretive guide, and doesn't confer special permissions. Given the amount of confusion that clause has caused, Lindberg considers removing it.

Fontana: The CAL is not Free because it encumbers APIs

In April, Pamela Chestek had asked why specifically the CAL should not be approved, under the assumption that public performance rights are a thing for APIs.

Richard Fontana responds:

  • it forces reimplementations of a CAL-covered API to be open source
  • Joke: any license can be opposed on the grounds that it violates OSD 5/6 (restricts some persons, or fields of endeavour)
  • but here the CAL really looks like such a violation
  • not necessarily a problem: even the GPL certainly restricts some persons
  • “From a software freedom perspective, extending a copyleft requirement to an interfae is unjust.”
  • CAL might violate the spirit of OSD 9 (don't restrict other software), similar to the SSPL.
  • OSI review should not just check OSD conformance, but also whether the license provides software freedom
  • the CAL's unreasonable burden on interface re-implementors violates software freedom.

  • that the license limits itself to copyright law doesn't mean it provides software freedom

  • a copyleft license like the CAL doesn't necessarily make more software available under open licenses.

    • unusual license might see no adoption
    • seems to serve a proprietary dual-licensing business model
    • which would mean it would actually result in less open software
  • questions what it means to publicly perform an API.

    • could see such a performance for GUIs
    • but APIs are not typically perceived by users

Pamela Chestek responds that she still can't see the CAL “as even slightly different from the GPL in reach”, under the assumption that API copyright exists. Chestek is more concerned about the applicability of public performance rights outside the US. Chestek is confused by Fontana's position that a free software license may not apply copyleft to all aspects of copyright (such as API copyright).

Chestek does not believe Fontana's argument that the CAL will result in less free software. If some copyleft licenses are harmful, where exactly is the tipping point? Why is AGPL acceptable but CAL not?

Fontana responds that a license may decide to cover API copyright, but no FOSS license should do so. Fontana thinks that the CAL breaks with the (A)GPL tradition, and is confident that the FSF would condemn any interpretation that the CAL were essentially the same as the GPL.

Perens: Licenses should not cover API copyright

Bruce Perens summarizes his stance on free software:

  • since the DFSG, it has been clear that running open source software for any purpose must be allowed
  • it is necessary that the rules don't have total sympathy for proprietary developers
  • it is fine to require the sharing of modifications
  • many network copyleft licenses change the fundamental deal of open source
    • running for any purpose no longer allowed
    • such licenses no longer respect users
  • approving network copyleft licenses is a slippery slope towards losing authority
  • supporting API copyright is a bad idea because it can be used against the open source community
    • perhaps later API copyright licenses will become necessary as a defense

On the interpretation of the OSD, Perens sees two ways forward: Either the OSD is interpreted literally, but is also amended/clarified regularly. Or, the OSD is interpreted intelligently.

Van Lindberg argues that “we have already entered the world in which licenses like the CAL are necessary”: “Put aside the network aspect. How many reimplementations of the GNU readline interface are there? How many bashisms have made it into other shells? Under Oracle v Google, those are derivative works.” Perens disagrees and urges not to “concede the fight before it is lost.”

Henrik Ingo agrees with Perens that the CAL oversteps some boundaries, in particular with its user data requirements. However, the age of SaaS makes strong network copyleft licenses necessary in order to protect end user freedom. Ingo hopes a scaled-down CAL would get approved.

To Peren's point that approving non-free licenses could cause the OSI to lose authority, Ingo adds that failing to approve OSD-compliant licenses would be harmful as well. “Network copyleft is clearly an area where currently supply and demand don't meet”. Perens obviously disagrees and reminds that approval can cause problems for the community. The community is also not reliant on OSI approving new licenses, just like the FSF doesn't have to write new licenses: “While we are starting to see reasons for GPL 4, nobody is in a hurry.”

Pamela Chestek [1,2] questions why involving public performance rights is necessary to protect APIs. “Public performance” is an US-specific term, and the CAL might stretch beyond the bounds of copyright. In contrast, the GPLv3 defines its term “propagate” in terms of copyright law. Chestek suggests the CAL could borrow this approach. Lindberg doesn't quite disagree, but objects on multiple points. The CAL should make its intention to cover public performance explicit, it already defines the term within the license, it must also consider IP other than copyright, it doesn't stretch beyond copyright, and Lindberg would like to stick to existing terms.

Freedom in Website and Blockchain Scenarios

Pamela Chestek asks whether she would be eligible to receive a CAL-covered websites source code when she enters a third party's user data into a form on the website. Van Lindberg responds that yes, she would be eligible for the source just as under the AGPL. However, the source code requirement already triggers due to using the software. Here, the third person's personal data is not that third person's user data, but the user data of the one entering the data into the website.

Bruce Perens [1,2] extends the scenario with a blockchain-based example, where there might be “derivative data”. Perens also thinks the CAL's definition of source code includes private keys that were used to manipulate data in the blockchain. After all, any blockchain participant would be an operator processing user data. (Note: this may be a misunderstanding of both blockchain technology and the CAL.)

Van Lindberg [1,2] provides two detailed replies. The CAL does not have a concept of derived data. Instead, obligations arise if someone is a Recipient in the sense of the license. The operator's obligation to provide data only extends to the user's data, and only to the extent that the operator can retrieve this data. Disclosure of private keys is not required in the context of user data, although it could be required in the context of the source code as part of the CAL's anti-Tivoization clause. In general, Perens's hypotheticals “don't really make sense”, and would result in roughly the same outcomes as under the AGPL.

Bruce Perens [1,2] claims that while the CAL may or may not violate the OSD, it definitely violates the FSF's Freedom Zero “to run the program as you wish, for any purpose”. The problematic user data terms even apply to unmodified software. In Peren's eyes, Lindberg has arbitrarily redefined the FSF's concept of Software Freedom to cover user data. Lindberg [1,2] insists the CAL ensures end user freedom the same way the GPL does, this involves preventing intermediaries/operators from taking rights away. The question to decide is precisely whether the operator's freedom to lock down end user data is more important than the end user's freedom to run the software with their own data. Lindberg and Perens just disagree on how to resolve that dilemma. Lindberg has also asked the FSF for their opinion.

Bruce Perens [1] also thinks the user data terms are unnecessary in the decentralized context for which the license was drafted. Lindberg argues that the CAL helps to keep a system decentralized.

Bruce Perens [1] sees an overarching problem with the license: that even competent attorneys seem to be struggling with its terms, particularly regarding user data and public performance. Courts might not share Lindberg's interpretation. Developers without legal counsel don't have the “slightest hope” of applying the license correctly. Lindberg [1,2] concedes that fully understanding a legal instrument like the CAL does require counsel. But the CAL is no more complex than the GPL. The effect of the CAL can be summarized concisely in a manner that would be understood by an ordinary developer. Perens [[1]perens:cal:competent2,[2]perens:cal:gpl-simple] [Perens]perens:cal:competent2 disagrees with that summary, and thinks Lindberg's stance is deeply unsympathetic to users.

Other Points

Re claim by Pamela Chestek: OSI decision making is unpredictable. Bruce Perens responds that “we like it that way”. OSI review should not mechanically implement pseudo-laws, but care about the community's interest.

Bruce Perens asks whether the copyright holder would also be bound by the conditions of the CAL, e.g. regarding user data. Peren's understanding is that they would not be bound, which would privilege them compared to other operators. Van Lindberg claims that the CAL places no party in a privileged position.

Van Lindberg argues that the CAL is also necessarily because the AGPL is so unclear and ambiguous. The CAL would be clearer, and would have applicable case law “at least by analogy”.

Kevin Fleming asks if the CAL is only fully effective if patents are involved. Lindberg responds that patents holders will have extra tools, but that the CAL is based equally on copyright, patents, and contract methods.

Pamela Chestek and Van Lindberg continue their review discussion from last month.

  • Lindberg updated language around the LGPL/MPL-style Combined Works exception.

  • Chestek thinks the anti-DRM clause is “unintelligible”. Lindberg provides a side by side comparison of the clauses in GPLv3 and CAL.

  • Chestek thinks the CAL is overly complicated when trying to ensure that all permissions are passed to downstream recipients. Isn't this as simple as “cannot impose additional restrictions”? Lindberg responds that this isn't as simple. He doesn't want to enumerate allowed restrictions like the GPL does. However, Lindberg updates relevant language in the CAL.

Henrik Ingo is torn on whether the CAL should be approved. Prima facie, the CAL violates the OSD – but only due to its well-justified, tightly-scoped user data requirements that are necessary to ensure end user freedom in practice: “the CAL is a net positive contribution to software freedom.” The user data clauses do not violate Freedom Zero if the operator is viewed as merely running the software on behalf of the end user. If this violates the OSD, maybe the OSD should be amended.

Bruce Perens [1,2] doesn't think the OSD can be a comprehensive list of allowed or disallowed license features. It should not be amended until it can be interpreted mechanically.

Ingo had invoked the License Zero review as precedent. Richard Fontana clarifies that L0 was retracted and not rejected, but that the significant past “hostile receptions” should be treated with some significance.

Lindberg's Summary

Van Lindberg [1,2] tries to summarize various objections and discussion points, and provides references to various arguments that have been made. The three main issues are:

  1. whether data portability can be guaranteed as part of software freedom and under the OSD
  2. whether public performance is effective, OSD-compliant, and good policy
  3. whether the CAL is too complicated or unclear

The objections mainly apply to the operator of the software, not to end users. Issues 1 and 2 are fundamental policy questions.

Bruce Perens confirms he believes that “an operator's ability to lock down the data they receive from end users is core to the OSD and to the concept of Free Software” (as phrased by Lindberg). John Cowan thinks Lindberg is approaching this from the wrong end: the right to commit crimes is not core to FOSS. But using FOSS licensing to enforce ethical actions is a Very Bad Idea.

Lawrence Rosen [1,2,3,4] is against approval. While Rosen accepts a public performance right for software (his own OSL uses it), it has limited value and has nothing to do with normal execution of the software. Performance does not include the rendering, display, or execution of a software. Rosen thinks the CAL's user data clauses are troubling, since data is not copyrightable. At most, a confidentiality clause would be appropriate. Lindberg [1,2,3] points out that the CAL has nothing to do with copyrightability of data, and uses a multi-pronged mechanism of which copyright is only one part. Lindberg thinks Rosen is reading the definition of public performance in US law too narrowly, and provides caselaw to bolster his argument.

Luis Villa argues that the CAL is not excessively complex. The CAL and GPL use similarly complex language, although both are more complex than other licenses. If objections on the grounds of complexity were to carry any weight, then “OSI can... only approve long-existing licenses (or trivial permissives). (If that's the board's intent I'd love to hear it; we can all unsubscribe from this list and call it a day!)” McCoy Smith concurs: there's a difference between ambiguity (bad) and inherent complexity (acceptable) of a license.

Pamela Chestek adds the major objection that the CAL would be the first open source license to encumber API reimplementations. This is the main issue, compared to any debates over public performance. Henrik Ingo argues that both are problematic, and that invoking public performance rights seems unnecessary except for the CAL's goal to implement API-copyleft. Lindberg views these issues as independent. The CAL's use of public performance is primarily an alternative to the AGPL's “network interaction” mechanism. API copyleft is a reaction to the Oracle vs Google case.

Richard Fontana thinks Lindberg's summary fails to accurately capture fundamental objections. The issue is not whether API copyleft could be premature, the whole concept runs against FOSS and industry conventions. If a license makes use of API copyright, then please only for maximally permissive licensing. Henrik Ingo thinks API copyright would be a huge detriment to the industry – would any readline implementation be copyright infringement? But if it happens, the FOSS community shouldn't just cede that ground. “Still, as long as we're not there yet, we of course shouldn't be the first party to strike.”

LBNL BSD

Sebastian Ainslie [1,2,3] asks for legacy approval of the LBNL-BSD, a 3-clause BSD variant used at the Lawrence Berkeley National Laboratory (LBNL). Compared to the common BSD template, it adds a caveat that U.S. Dept. of Energy approval may be required, presumably required for all DOE labs. It also adds a paragraph that published modifications fall under the same license by default. This is a bit like an implied CLA, or like copyleft with an opt-out. Ainslie explains this is necessary in order to accept contributions without signed CLAs.

Legacy approval

There is some contention on what legacy approval signifies.

Bruce Perens raises a license proliferation objection. McCoy Smith wonders why OSI approval is needed if the license has already been used for over a decade. Richard Fontana wonders whether actively used licenses are eligible for legacy approval. Kevin Fleming assumes that the use of legacy-approved licenses would be discouraged. On further reading, Fontana finds that legacy approval is just retroactive. It does not require the license to be unused, and does not imply any discouragement.

Richard Fontana [1,2] thinks that legacy-approval must generally meet the same standard as new licenses, especially with regard to OSD conformance. But it would be a good idea for OSI to take a more active role to explicitly approve licenses that are commonly used in Linux distributions. Legacy approval should therefore be more lenient about sloppy or amateurish drafting. 15 or 30 years ago, licenses simply were not drafted with the same standards we expect today.

Fontana sees many people who do not accept OSI's stewardship of the Open Source definition. They can point to a vast collection of open source software that does not use OSI-approved licenses. A mass effort to approve more obviously-FOSS licenses would then have some benefit.

Actual review

Fontana sees the added paragraph as unclear or sloppily drafted. It might not trigger the default license if modified versions are privately given to third parties, without these modifications being published. This is different from Apache 2 which just codifies the “inbound = outbound” expectation. Pamela Chestek [1,2] wonders whether the paragraph is even relevant: “inbound = outbound” is the default expectation, with or without that paragraph. The paragraph mainly affirms that modifications can be published under a different license. Henrik Ingo shares this view (see also below). John Cowan disagrees: by default the modifications would have no license, as the BSD would only apply to the original work.

Tom Callaway questions why the paragraph seems to assign different terms to enhancements than the main BSD license. Richard Fontana too thinks that the contributor license is broader than the BSD. Ainslie [1,2] argues that no such different terms are used, but this seems to confuse the submitted license with a suggested simplification by Callaway.

McCoy Smith and Henrik Ingo note that OSI usually rejects licenses that give preferential treatment to one party, or are specific to some entity. Here, this is not a problem: while the LBNL is mentioned explicitly as a recipient, it receives the same rights as the public.

Henrik Ingo is slightly concerned about the default license paragraph acting like an implicit contributor agreement. But this is not a problem in practice: code added to a BSD-licensed project is considered to be BSD-licensed as well. The paragraph only seems like a clarification in case of a standalone patch is sent without explicit license indicators.

Brendan Hickey isn't sure whether implicit “inbound = outbound” should be promoted. Hickey points to projects like Linux that expects patches to be explicitly signed off by the contributor. Hickey also points to the C-FSL review, where it was discussed that licenses cannot do copyright assignment. So what kind of licensing terms would actually be necessary in order to safely accept contributions? Henrik Ingo responds that the license status of published modified versions is usually clear without having to take extra steps, and that no copyright assignment is involved.

Richard Fontana suggests a DCO (https://developercertificate.org/) as a simpler way to ensure that contributions are properly licensed.

Ainslie says that DOE labs cannot use a vanilla BSD license, which made small changes to the license necessary. Pamela Chestek [[1]chestek:lbnl:doe,[2]chestek:lbnl:doe2] [Pamela Chestek]chestek:lbnl:doe asks for documents that require these changes and McCoy Smith asks which specific changes are mandated. Ainslie says they have to attribute their funding source and add a notice that DOE approval be required. McCoy Smith questions whether the addition of a notice even creates a new license. It is unclear to Chestek which of these changes are part of the license that is under review.

McCoy Smith [1,2] thinks making the license conditional on DOE approval could be an OSD 7 issue. But is that a license condition, or just a notice?

Pamela Chestek asks how many projects use this LBNL license. Ainslie says it's used by nearly all open source software from Berkeley Lab, adding up to hundreds of releases.

Master-Console

Wayne Rangel Wayne Rangel [1,2] submits the “Master-Console's Open Source Definitive License” for approval. It is difficult to tell, but the rationale for this license seems to be:

  • that the original author can take down malicious modifications
  • that the source code shall be offered in a specific manner, presumably that the source code can be downloaded via a web browser

Lukas Atkinson expresses their frustration that the license seems impossible to understand, both from a legal perspective and due to the unidiomatic English. Christoper Sean Morrison thinks “that should be grounds for rejection alone.” McCoy Smith sees the license terms as an OSD 5/6 violation. The license is also likely non-free, “although the wording is such that I can’t quite tell.” Bruce Perens points to the Artistic License as an example where an unclearly drafted license resulted in high costs to third parties.

Richard Fontana suggests the license is not yet ready for review. Pamela Chestek [1,2] asks for the license to be retracted from review.

Help Wanted!

Our current editor of the monthly License-Discuss and License-Review reports, Lukas Atkinson, will not be available to continue in June and July, and may have limited availability throughout the rest of the year. If you would like to join the OSI as list editor, or know someone who might, please contact OSI General Manager Patrick Masson. The list editor works on a freelance basis to provide monthly summaries of the License-Review and License-Discuss mailing lists.

Categories: FLOSS Research

May 2019 License-Discuss Summary

Mon, 2019-06-03 18:21

In May, the License-Discuss mailing list talked about:

  • relationship between the License-Review mailing list and the License Comittee
  • evolution of the license review process
  • comprehensiveness of the approved license list
  • licenses of licenses
  • would three licenses be enough?
  • email threading

The corresponding License-Review summary is online at https://opensource.org/LicenseReview052019 and covers extensive debate on the Cryptographic Autonomy License, as well as discussion on a BSD license variant.

License-Review / Committee Relationship

In the review of the CAL, a minor point was whether the review of the License Zero should be characterized as a “rejection”.

Luis Villa talks about the history of the License-Review list, that the list at times was an OSI committee, but that any decision making authority lies solely on the OSI board.

Richard Fontana feels that community engagement in the list has declined, making it more difficult for OSI to argue that review decisions reflect community consensus.

Luis Villa isn't sure that engagement has gone down, but thinks the level of engagement is definitely unhealthy – 100+ email threads chase away potential submitters.

Henrik Ingo likens list participation to jury duty. Ingo also points out that there is no need to chime in to repeat a consensus opinion.

Christopher Sean Morrison agrees with Ingo's point that mailing lists dictate “efficient silence”, without a mechanism to silently signal agreement. But engagement also suffers from “rehashed-topic fatigue”.

Pamela Chestek sees some bullies on the list. Someone may stay silent not out of agreement, but to avoid conflict.

Nigel Tzeng suggests anonymous voting by OSI members. (Note: but that doesn't help with discussions.) Fontana thinks that would be ripe for abuse. Tzeng thinks the current system can also be abused, presumably referencing the NOSA review.

Scott Peterson argues against maximally precise rules, both regarding the review process and possible OSD amendments.

McCoy Smith views the board elections as a kind of indirect vote. Henrik Ingo warns that direct democracy can distort a vote. The OSI board must make decisions on their own responsibility.

Evolving the License Review Process

Pamela Chestek announces the new OSI License Review Committee, consisting of Pamela Chestek (chair), Elana Hashman, Chris Lamb, and Simon Phipps. They recognize the need for improvement of the review process, so that all points of view are represented in the discussion. As a first step, they clarify:

  • License-Review list collects feedback from the public about proposed licenses. The Comittee considers these responses when making their approval recommendation to the OSI board. If a license is not yet ready, a moderator can move discussion to License-Discuss.

  • License-Discuss is for general questions about open source licenses, and for licenses in their early stages of development. It is recommended to develop new licenses in the open, and to regularly seek feedback from License-Discuss.

  • There will be an effort towards better moderation, to ensure appropriate conversation and a good pace of discussion, and to encourage wider participation. This includes rules to limit hostility, frequency, and repetitiveness of messages, includes follow-ups from moderators to unanswered questions, and includes enforcement of the existing Code of Conduct.

  • The website now clarifies the license review process: community consensus is no longer a precondition. Instead, the board takes the community discussion into account for its decision.

Simon Phipps clarifies that Chestek's announcement represents the decision of the OSI board.

Bruce Perens perceives this change as directed squarely against him. “I, and others, have today been ejected from the license committee.” (Note: this assumes the view that the list members are the committee.) Perens does not think the mere number of messages would be a problem – they are necessary to clarify important questions. Perens doesn't see the point in accommodating people who don't (yet) participate on the list.

Chestek disagrees with the characterization that anyone would have been ejected – instead, these changes have the goal of inviting more diverse responses than is currently the case. Chestek points to concrete examples how Peren's messages come across as agressive: “this is a tone and style of engagement that is inappropriate.” Perens feels this rejects his viewpoint without appropriate concern.

Russel McOrmond lauds Perens for being a persistent advocate of software freedom, and urges him to not take push-back personally.

Lawrence Rosen appreciates the clarity of the new process, but thinks there is too much focus on strict codes of conduct. Just delete the emails you don't want. Rosen is also surprised to recently learn that Perens represented the OSI in their open standards activities (Perens responds). It is important that it's clear within discussions who speaks for OSI and who doesn't. Rick Moen concurs, and urges everyone to assume good faith. Moen also makes a distinction between different kinds of mailing list moderation. In a certain sense, the OSI lists are unmoderated.

Perens responds to Rosen's aside about standards engagement. Perens also thinks any accusations of bullying are over the top, and that these changes to the list are just tone policing. Perens cautions that “license submitters will tell the story as it is most advantageous to them”, especially if they are lawyers. It's important to be able to call that out when it happens. John Cowan thinks Peren's point about lawyers is counterfactual. There's a difference between rethoric and outright misrepresentation.

Chestek agrees with Rosen that all opinions should be heard, but these can't be expressed in any way you want. A “deal with it” attitude alienates valuable voices. In contrast: “I've never heard of a forum where people won't participate because it's too polite”. Rosen thinks some blustering is normal for lawyers, and that politeness is not generally necessary: “That is boring. We are adults here.”

James thinks moderation should only be done as last resort and as transparently as possible because it can have chilling effects. John Cowan recalls moderation activity on Fidonet: moderation isn't as large a problem as it might seem, and bans were well-deserved.

Fontana appreciates the improved clarity brought through Chestek's changes. The (purely advisory) role of the License-Review list is a major change of how the process is described, but it reflects the actual process more accurately.

McOrmond thinks the line between passion and rudeness is too subjective to be useful. Strict focus on a CoC would exclude passionate people. Some amount of shared views are necessary in a community. Rick Moen counters: it's perfectly possible to find some common ground and cooperate with people whose views clash. The OSI list “is a natural place for people supportive of OSI's real-world objective.”

There is a bit of a side discussion about threats to and core issues of FOSS by McOrmond [1,2] (Affero etc is a threat), Perens (Affero is fine), Simon Phipps (the rules serve the movement), and Moen (software freedom is a shared value).

Martijn Verburg chimes in with an assessment that OSI's list are more “robust” than others. “An attempt to make both lists more welcome to voices […] can't do any harm.”

Moen suggests a conspiracy theory: that these claims of uncivility arose after the OSI didn't approve certain licenses. Are sinister forces trying to silence effective critics? Would those more diverse views not be more sympathetic to such rejected licenses? (Note: it's impossible to tell to which degree this is joking.) Chestek responds: “I understand that people on this list may be skeptical of my commitment to software freedom and/or open source software”. But the Committee and the Board are more than a single person. “I do hope that simply having a different opinion on the meaning of software freedom at the fringes doesn't mean that one has become captive of anti-freedom forces.” The OSI is working on important problems, such as the function of the lists, the quality of the review process, and the exact scope of open source.

Henrik Ingo writes a detailed response to various points.

  • the review process hinges on the few who can actually dissect the licenses and read all the emails
  • the list seems comparatively disciplined, aside from discussions that rehash long-past reviews
  • the SSPL review saw an influx of new participants. Where there were problems, the list self-regulated
  • that a new board points to the existing CoC shouldn't be news
  • it is more concerning “that the board believes there is an actual issue that needs fixing”
  • some of the “concerns” on the list are just lawyerly bickering or lobbying to change OSI policy
  • in many of the mentioned cases, the reasons for non-approval are perfectly clear and don't have to be relitigated constantly
  • OSI review is not a court, no cases are lost – revised licenses could be approved
  • review is not just about checking whether the OSD applies, but also about how the new license serves the community
  • it is not sufficient that a license does no harm
  • license review is a lot like “code review”, in the sense that there is a kind of shared ownership
  • whereas the FSF's Four Freedoms have significant backing material and discussion, the OSD seems so unanimous and obvious that no comparable body of commentary exists
  • maybe that is a problem, and more commentary would help?
  • the process seems to be working better than ever, so why fix it?

Richard Fontana thinks the review process is perceived as unpredictable because few licenses make it to a board vote. Those that do tend to be obvious cases and don't need a rationale. Most problematic licenses are retracted by the submitter due to community feedback. Fontana also thinks the OSI has a problem dealing with mistakes, such as approved licenses that are not open source under current understanding. A de-listing procedure might be necessary.

Henrik Ingo thinks outright de-listing would be problematic. As a first step the license stewards could be asked for voluntary retirement of the licenses. Otherwise, they could be moved to a “not recommended” category that recognizes that they were used in good faith.

Nigel Tzeng thinks de-listing licenses would be problematic because they would likely target special-purpose licenses. Tzeng is particularly concerned about the (lack of) acceptance of Government Open Source (GOSS) licenses. (Note: due to overwhelming volume and limited novelty, this summary will not cover the ensuing discussion about GOSS.) Regarding possible delisting, Perens states that it is not OSI policy to promote some licenses over others, beyond marking some as “legacy”. Even though in practice, three licenses would be enough (see separate section).

Tzeng doesn't think his perception that the lists are dominated by Perens and Fontana should be treated as an ad-hominem attack. Perens responds that having an assertive personality paired with relevant expertise should be fine Rosen [1,2] disagrees most harshly, Perens wonders how that response can be anything but ad-hominem. Henrik Ingo expresses the meritocratic view that Peren's and Fontana's influence is mostly a consequence of all the time they spend reviewing licenses.

Luis Villa thinks Chestek's clarifications are fantastic, but is concerned that the meaning of “software freedom” is still unclear in an OSI context. Villa notes that while these improvements target the decision-making process, improvements might also be needed for the record-keeping process. The list archives are an unsuitable medium, instead authoritative summaries are needed. Villa provides some links on RFC-like processes. This seems similar to the March 2019 discussion whether a PEP-style process would help.

Comprehensiveness of the Approved License List

Luis Villa argues that the list of OSI-approved licenses isn't a comprehensive list of usable open source licenses. It should therefore be avoided in contracts or license clauses. But if not that, what is the purpose of the list? Would it make sense to create a smaller list of useful licenses? Villa points to his Blue Oak project as a list of useful permissive licenses.

Richard Fontana thinks the approval process is more important than the resulting list. In a way, the licenses are just a medium through which “open source” is clarified. Fontana also warns against relying on self-appointed authorities, and notes that OSI's License-Review is more transparent than alternatives.

Ben Hilburn [1,2] thinks this discussion is important, but finds Fontana's standpoint confusing. Whether a license is “open source” is defined by its OSI approval. Otherwise, how could OSI be an arbiter of that term?

Nicholas Weinstock insists that the OSD and not the review process is the definition of open source. It follows that the OSD is not just a bunch of factors to consider during review. It also follows that licenses can be open source without being OSI-approved. Too much focus on the list of currently approved license would also result in a weird status for legacy licenses that have since been removed from the list.

Van Lindberg likens OSI approval to a product certification. It doesn't matter whether something is potentially approvable, only whether it has been approved. In the end, it must be OSI's call to decide whether a license satisfies the OSD. In contrast, the term “Free Software” could be used more freely. Nicholas Weinstock disagrees with Lindberg's comparison: OSI approval is not a completely neutral review, but takes wider concerns into account.

Lindberg argues that only OSI-approved parts of a Linux distro should be called “open source”. There needs to be some definition of that term, and clearly it is for the OSI to decide what it means.

McCoy Smith [1,2] links to OSI's deprecation/retirement category (https://opensource.org/licenses/category) which “should not be used to license any new code.” Lindberg [1,2] claims that it is not clear whether such licenses still are open source. Lindberg suggests a cut-off date.

John Cowan argues that “law is whatever the judge says”, here: open source is whatever the OSI says. It is then perfectly fine to refer to the list of OSI-approved licenses. It is just that this view provides no guidance for OSI's review process. This approach works fine as long as OSI's decisions do not deviate too far from community expectations.

Stephen Paul Weber occasionally sees such “any OSI-approved license” terms in contests or in aggregators. Sometimes, any OSI- or FSF-approved license is allowed, to avoid choosing “sides”. Fontana thinks that approach is clever: both OSI and FSF are respected neutral authorities, unlike e.g. Blue Oak or Fedora. As a historical point, Fontana remembers that Fedora did not rely on the OSI license list because OSI was then seen as too commercially influenced. Nowadays, OSI criticism seems to be the opposite. Henrik Ingo thinks the OSI is now much more important than back then, because Linux distros no longer have the role of kingmakers: whether the software is packaged for Debian or Fedora is no longer crucial for an open source project.

Ingo doesn't think the OSI license list should even try to be comprehensive. Most open source software is covered by a handfull of licenses, but there is a long tail of presumably-compliant licenses. Those can be approved when they are submitted, but there's no need to actively seek them out. Fontana does see some value in mass legacy approval: licenses without OSI approval are common in Linux packages. Approval would defuse the claim that these weren't open source. Ingo thinks distros have different motivations than the OSI. For example, the OSI did not approve the libpng license – but Linux distros will continue to ship it.

CC0 and Patents

Weinstock had mentioned the failure to approve CC0 even though it was OSD-compliant. Fontana interjects here: there are grave concerns because it explicitly does not license patents. Nigel Tzeng [1,2] retells the history of 2012 CC0 review, claiming that it was not as simple as Fontana purports. The CC0 is now a widely used open source license, despite not being OSI-approved. In contrast, Henrik Ingo and Rick Moen recall that Fontana's concerns were a quickly growing consensus. Fontana goes into more depth about his motivations at the time. The CC0 review helped build an understanding of the issues around patents in open source.

Christopher Sean Morrison thinks the problem is that the OSI has no clear policy on the role of patents. If patents are involved, a licenses that excludes them arguably violates OSD 7. But without patents, such a license would be still OSD-compliant. (Note: but compare also Fontana's message referenced above.)

With regard to the role of patents, Rick Moen [1,2,3] argues that having an open source license is a necessary but not sufficient precondition for a software actually being open source. As a hypothetical, Moen considers a jurisdiction that somehow encumbers a BSD-licensed software.

John Cowan [1,2] disagrees with the premise of Moen's hypotheticals. The biggest patent threat to open source software is not from authors but from third parties. It isn't possible to conclusively determine whether some software is safely open-source. Rick Moen doesn't think that stance is workable. Open source software should be called open source, until the day that the software is encumbered by a concrete threat.

Nicholas Weinstock agrees with Cowan's analysis. But it would be useful to discuss open sourceness of licenses separately from the licensed programs. The OSD does not make such a distinction consistently.

Van Lindberg argues that open source only describes the licensor–recipient relationship. Third parties are out of scope, and no warranties about this are given by the license. Moen agrees, but this doesn't change the issue that software cannot be distributed freely if there are claims against it by a third party.

Lawrence Rosen notes that some licenses have defensive termination clauses that may be a sufficient defense against third party patent threats. (Note: Apache 2 and GPLv3 have such clauses.) Bruce Perens is concerned that such clauses could be ineffective if a company moves the patents to a separate entity.

The GPLv2 includes a “freedom or death” clause that can prohibit distribution in certain jurisdictions. Fontana is of the opinion that software ceases to be open source if this clause is invoked.

As an aside about the BSD, Lawrence Rosen suggests it's the OSI's responsibility to warn the public that BSD is not a useful license due to its lack of a patent license – “Use a professional license instead!” Morrison thinks that is baseless fear-mongering. Has this risk actually been tested? McCoy Smith doesn't recall caselaw, but links to academic literature.

License Licenses

Patrick Masson wants to update the OSI license list to include metadata about the license, such as the license of the license text.

Thorsten Glaser provides metadata for his MirBSD license, but notes that no license for it's text has been adapted.

John Cowan links to/extracts the relevant licensing information from GPL, EPL, Apache 2, MPL 2, CDDL and points out that MIT/BSD are freely modified in practice. Lawrence Rosen extracts the relevant paragraph from the OSL.

Richard Fontana cautions that the license submitter and the copyright holder can be distinct, and that noting a copyright holder is not always useful. E.g. the MIT license has no copyright owner, no license steward, and isn't even affiliated with the MIT. (McCoy Smith links to some MIT archeology). It is also questionable whether licenses are copyrighted in general. (Perens concurs). In contrast, Pamela Chestek provides precedent in favour of copyrightability for legal documents. “To those of us who write them, they are as creative as code.”

Three Licenses

How many licenses does one actually need?

Bruce Perens Bruce Perens [1,2] suggests that three licenses should be enough for anyone: AGPLv3, LGPLv3, and Apache 2. They are mutually compatible, OSI and FSF approved, have explicit patent terms, and cover a wide range of license goals from permissive to network-copyleft. Why not guide people towards this “strategically coherent” set?

John Cowan answers: because that would look like ASF/FSF favoritism.

Brian Behlendorf agrees that dealing with dozens of subtly different licenses is tiring. But OSI's legitimacy derives from its principles. Favoring some licenses (and neglecting others) would call that legitimacy into question. But it would be fine to educate potential licensors about license features, and encourage them to stick to the more common set.

Rosen's mention of the OSL elsewhere prompts John Cowan to announce his dislike of the license: it establishes a separate incompatible copyleft ecosystem or commons from the GPLv2 and GPLv3 ecosystems that already exist.

Rosen disagrees. Copyleft licenses are generally compatible regarding aggregations or collective works, and incompatible regarding joint or derivative works. But that isn't a problem because joint derivative works are rare in practice. The GPL/AGPL group is the odd one because the FSF interprets them to apply to static linking and other interactions. That is a problem with the FSF interpretation, not with copyright law.

Thorsten Glaser accuses Rosen of promoting an agenda here, and that the GPLv2/GPLv3 ecosystems are much more important in practice than the EPL/MPL/OSL ecosystem.

Topicality and Email Threading

Kevin Fleming is frustrated that discussion threads are often derailed by tangential discussions. Such discussions should be split off into a separate topic, so that other people don't have to wade through off topic discussion to find the relevant parts. Discourse allows messages to be moved to new topics after the fact.

John Cowan thinks that threading mail readers help, but that some amount of topic intermingling is unavoidable in any medium. Rick Moen shares the sentiment that threading is easy. “The above is internet 101 […] dont't blame the tool when the user cannot be bothered”. Regarding Discourse, it doesn't show any threading within a topic.

Luis Villa sees these OSI mailing lists as a disproportionally email-entrenched group. And even here, threading does not work in practice – hardly a case of Internet 101. This is dysfunctional. Having to master advanced email techniques seems like an unnecessary barrier to entry. Thankfully, other software does not blame the user – Discourse tries “to reach users where they actually read and write”. Moen responds.

Other discussions

Nigel Tzeng feels that the License-Review list was much more diverse in earlier times (2012), but is now dominated by Richard Fontana and Bruce Perens. Even though everyone is acting in good faith, this hurts engagement on the list. Bruce Perens notes he had been absent from the list for many years, only participating again since mid 2018. Were things really so different back in 2012? In the archives, Perens mostly finds the same posters as today.

Help Wanted!

Our current editor of the monthly License-Discuss and License-Review reports, Lukas Atkinson, will not be available to continue in June and July, and may have limited availability throughout the rest of the year. If you would like to join the OSI as list editor, or know someone who might, please contact OSI General Manager Patrick Masson. The list editor works on a freelance basis to provide monthly summaries of the License-Review and License-Discuss mailing lists.

Categories: FLOSS Research

Open Source Initiative Announces New Partnership with Software Liberty Association Taiwan

Wed, 2019-05-29 14:37

The Software Liberty Association Taiwan joins long list of Open Source Initiative Affiliate Members and growing representation in Asia.

PALO ALTO, Calif. - May 20, 2019 - The Open Source Initiative ® (OSI), the global organization working to promote and protect open source, is excited to announce the Affiliate Membership of the Software Liberty Association Taiwan (SLAT). Founded in 2001, SLAT is Taiwan’s first legal entity dedicated to Free and Open Source Software (FOSS), supporting both the development and user communities.  As an active community of advocates and technologists, SLAT both drives initiatives, and partners with existing projects, to promote FOSS, including the Open Source Software Application Consulting Center—a program fostering FOSS in Taiwan's schools.  

Critical to both the OSI's and open source projects' success is, as stated in the OSI mission, "building bridges between communities." Both the OSI and SLAT believe those organizations serving Free and Open Source Software communities should seek out ways to support each other—SLAT's Affiliate Membership is an excellent example of such collaboration.

“We’re thrilled to have SLAT join us in our work to advance Open Source Software and foster open source development,” said Patrick Masson, OSI General Manager. ”SLAT is already doing amazing work throughout Asia, and I hope we can compliment their efforts, and even help expand their good work through other OSI Affiliates. Open Source Software is a world-wide phenomena, so the OSI must commit to working globally.”

"We found a blue ocean in the world of FOSS," said Franklin Weng,  former SLAT president and current executive director. "Many  educational applications simply aren’t profitable enough for proprietary vendors to invest in  however are vital to students and schools . FOSS plays a critical role in educational software: programs like Kanagram, Geogebra, GCompris, Kalzium, Stellarium, and Kmplot, covering all kinds of subjects, and making education accessible.  Everyone, every kid, no matter rich or not, elite or not, they all can use these resources in their learning."

In  2015, SLAT launched the Software Liberation Movement, The goal, “explain to people that they have the freedom to choose whatever software tools they need according to their real-world requirements," explained Weng. "We, the users,  should be the ones who determine which tools we use for achieving our goals. However in reality, most people are bound by limitations or restrictions inherent to proprietary software.  We'd like to make people aware that they have many choices, and Open Source Software should be like that of 'public infrastructure' in the physical world—just like buses, trains, accessibility facilities, etc. The value of public infrastructures lies not in how many people are using them, but in the fact that they exist when people have such requirements."

Most recently SLAT has begun promotion of “Public Money Public Code“ in Taiwan. Such policies require that publicly financed software developed for the public sector be made publicly available under a Free and Open Source Software licence. “If it is public money, it should be public code as well.”  Again Weng, "OSI and SLAT are both committed to educating people about open source -- its spirit and value. The OSI reviews and certifies open source licenses, which we think is very important, clearly identifying what is open source. It's very important developers in Taiwan use OSI approved open source licenses. We're very happy to join OSI as an Affiliate Member to, together, support  initiatives like the Software Liberation Movement, and Public Money Public Code."

The OSI Affiliate Member Program is available at no-cost to nonprofits, educational institutions, and government agencies that support the OSI's mission 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 Software Liberty Association Taiwan
Founded on April 8, 2001, the Software Liberty Association (SLAT) is dedicated to serving the free and open source community, promoting free software and open source applications to promote community growth.To learn more about SLAT, visit: https://slat.org/

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

Open Source Initiative Announces New Partnership with Software Liberty Association Taiwan

Wed, 2019-05-29 14:36

The Software Liberty Association Taiwan joins long list of Open Source Initiative Affiliate Members and growing representation in Asia.

PALO ALTO, Calif. - May 20, 2019 - The Open Source Initiative ® (OSI), the global organization working to promote and protect open source, is excited to announce the Affiliate Membership of the Software Liberty Association Taiwan (SLAT). Founded in 2001, SLAT is Taiwan’s first legal entity dedicated to Free and Open Source Software (FOSS), supporting both the development and user communities.  As an active community of advocates and technologists, SLAT both drives initiatives, and partners with existing projects, to promote FOSS, including the Open Source Software Application Consulting Center—a program fostering FOSS in Taiwan's schools.  

Critical to both the OSI's and open source projects' success is, as stated in the OSI mission, "building bridges between communities." Both the OSI and SLAT believe those organizations serving Free and Open Source Software communities should seek out ways to support each other—SLAT's Affiliate Membership is an excellent example of such collaboration.

“We’re thrilled to have SLAT join us in our work to advance Open Source Software and foster open source development,” said Patrick Masson, OSI General Manager. ”SLAT is already doing amazing work throughout Asia, and I hope we can compliment their efforts, and even help expand their good work through other OSI Affiliates. Open Source Software is a world-wide phenomena, so the OSI must commit to working globally.”

"We found a blue ocean in the world of FOSS," said Franklin Weng,  former SLAT president and current executive director. "Many  educational applications simply aren’t profitable enough for proprietary vendors to invest in  however are vital to students and schools . FOSS plays a critical role in educational software: programs like Kanagram, Geogebra, GCompris, Kalzium, Stellarium, and Kmplot, covering all kinds of subjects, and making education accessible.  Everyone, every kid, no matter rich or not, elite or not, they all can use these resources in their learning."

In  2015, SLAT launched the Software Liberation Movement, The goal, “explain to people that they have the freedom to choose whatever software tools they need according to their real-world requirements," explained Weng. "We, the users,  should be the ones who determine which tools we use for achieving our goals. However in reality, most people are bound by limitations or restrictions inherent to proprietary software.  We'd like to make people aware that they have many choices, and Open Source Software should be like that of 'public infrastructure' in the physical world—just like buses, trains, accessibility facilities, etc. The value of public infrastructures lies not in how many people are using them, but in the fact that they exist when people have such requirements."

Most recently SLAT has begun promotion of “Public Money Public Code“ in Taiwan. Such policies require that publicly financed software developed for the public sector be made publicly available under a Free and Open Source Software licence. “If it is public money, it should be public code as well.”  Again Weng, "OSI and SLAT are both committed to educating people about open source -- its spirit and value. The OSI reviews and certifies open source licenses, which we think is very important, clearly identifying what is open source. It's very important developers in Taiwan use OSI approved open source licenses. We're very happy to join OSI as an Affiliate Member to, together, support  initiatives like the Software Liberation Movement, and Public Money Public Code."

The OSI Affiliate Member Program is available at no-cost to nonprofits, educational institutions, and government agencies that support the OSI's mission 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 Software Liberty Association Taiwan
Founded on April 8, 2001, the Software Liberty Association (SLAT) is dedicated to serving the free and open source community, promoting free software and open source applications to promote community growth.To learn more about SLAT, visit: https://slat.org/

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

OSI License Discuss and Review: Evolution and Improvement

Fri, 2019-05-24 15:41

Summary
The directors of the board of the Open Source Initiative recognize the process for discussion and review of new licenses proposed for approval by the organization can use improvement and would benefit from evolution. In particular, it does not appear as though all points of view on open source licensing are represented in the discussion here. To address this situation we have created a Board Committee for license approval to evaluate responses on-list, appointed more moderators, and will devise a new moderation strategy.

Proposal
We anticipate that the effort to improve the quality of discussion on the license lists will be an iterative process. This email describes our first step, which is to approach the community and elicit feedback on this approach. We anticipate further steps including a review of tools, but we’re not yet at that stage.

Channels
License review vs. License discuss lists

License-review(a)lists.opensource.org is the email address for submitting a license for which you seek OSI approval following the process at https://opensource.org/approval. The list is open to the public, so anyone can give their opinion about a license. The OSI License Committee considers the viewpoints expressed on the license-review list in making its license approval recommendation to the OSI Board. Since the purpose of the list is to inform the Committee and the Board, discussion of substantive issues off-list is not recommended. If a license submitter elects to respond to a substantive question submitted to them off-list, the submitter is encouraged to copy the license-review list also on their response after redacting the identity of the person sending the communication.

License-discuss(a)lists.opensource.org is for general questions about open source licenses and for licenses in early stage development. The list is open to the public and anyone can give feedback. A moderator may decide that a license submitted to license-review isn’t sufficiently developed and will move it to license-discuss for additional work. We recommend that you carry out your license development process on a publicly viewable venue (preferably one where collaboration is also possible) and regularly seek views on license-discuss. Note that agreement on license-discuss does not guarantee agreement on license-review, as the audiences differ.

Moderation
The board recognizes that the license-review mailing list would benefit from further, more concerted moderation, both to ensure appropriate conversation and to maintain the pace of discussions. This more concerted process will evolve in the following steps:

  • We will develop rules to encourage wider participation. We perceive that some are discouraged from participating because of offensive tone, frequency, or repetitiveness of messages. We will develop moderation standards to address these hurdles.
  • A moderator will also advance the conversation, by following up with the license steward on unanswered questions and ensuring that all topics of interest have been fully fleshed out.
  • We will assure observance of the Code of Conduct for the mailing lists, available at: https://opensource.org/codeofconduct/licensing.

Changes to the Website
We have also made a minor change to the language describing the license review process on https://opensource.org/approval. The page formerly said “Approve, if (a) there is sufficient consensus emerging from community discussion that approval is justified, and (b) the OSI determines that the license conforms to the Open Source Definition and guarantees software freedom." The page now says “Approve if, after taking into consideration community discussion, the OSI determines that the license conforms to the Open Source Definition and guarantees software freedom.”

We have also clarified the timing of the review decision.

License Review Committee
The License Review Committee is an OSI Board committee made up of the following board members, as of May 2019:

Pamela Chestek, chair, pamela.chestek(a)opensource.org
Elana Hashman, elana.hashman(a)opensource.org
Chris Lamb, chris.lamb(a)opensource.org
Simon Phipps, webmink(a)opensource.org

The License Review Committee will summarize and report the license-review discussions to the Board for the Board’s approval or disapproval of a proposed license. Members of the Committee also serve as moderators for the two mailing lists.

What We’re Asking
If you have not already done so, please subscribe to the license-review and license-discuss lists. And then contribute. More participants will help us ensure that every viewpoint has been heard and considered by the collective, so that the OSI's actions are truly representative of the open source community.

 

Categories: FLOSS Research

2018 Open Source Initiative Annual Report

Fri, 2019-05-24 15:03

Welcome to the Open Source Initiative’s 2018 annual report. In this year's report you’ll learn about the organization’s activities from the past year, which captures the hard work of employees, contractors, volunteers, and those passionate about open source. I hope this will give you some context on why this work happened and what makes it so important. The Open Source Initiative was started in 1998 by a group of people interested in seeing ethics applied to the creation and distribution of software. This approach was built on a foundation of ideals – a specific philosophy on the rights and responsibilities of software users and creators. More than twenty years later, I am writing as a director of the OSI, which has grown into a robust organization with record numbers of individual and affiliate members, a dedicated all volunteer board, and the incredible support of volunteers and open source enthusiasts around the world.

2018 brought amazing successes for the OSI. We celebrated our 20th anniversary, which took us around the world where we were able to look back on thousands of victories for open source. Every line of code or translation; every piece of documentation and version controlled repository; every successful business, happy user, and committed contributor, continues to shape a movement that has changed the face of technology, business, and community. It was also a year in which Microsoft acquired GitHub, one of the largest distributors of open source licensed code, and IBM purchased open source business giant Red Hat, showing that the companies that built their success around proprietary software see the need for an open source future.

The past year also brought new questions on the validity of the Open Source Definition; the role of open source licensing, and both copyleft extension and enforcement; and individuals and organizations challenging the work of the OSI and the open source community as a whole. This included the legal battle concerning Google’s use of Oracle America’s APIs, and the creation of the Commons Clause, which renders any previously open license no longer OSD-compliant. I view these as challenges we need to meet, and illustrations as to why the the OSI is as important as ever. I am certain that the open source community will rise to the occasion.

It is thanks to your support, interest, and work that the OSI is able to continue our efforts to support software freedom by maintaining the canonical list of open source licenses, providing a home for new projects and community initiatives, and bringing attention to the necessity of open source in the future of computing. The values that drive the OSI have had a demonstrable impact on the world, bringing new approaches to the ethical considerations facing everyone creating and interacting with computing technology and beyond. We see adoption of open source ideals not just in software, but in art, design, publishing, and science. Looking back on 20 years of open source ideology, we see twenty fruitful years of collaboration, contribution, and community that have spawned a philosophy of openness across fields of endeavor. Here’s to 20 more years of open source!

Molly de Blanc
OSI Board President

Categories: FLOSS Research

You're Invited: Celebrating Powering Potential.

Wed, 2019-05-22 19:13

OSI Affiliate Member Powering Potential Inc. (PPI) is currently preparing for their annual fundraising event scheduled for Wednesday, June 5, 2019, from 6 to 8:30 p.m. at NoMad Studio, located at 29 W. 39th Street, 10th Floor, in New York City.

This year PPI celebrates their 10 Year Partnership with the Segal Family Foundation. The close, long-time relationship has been a key factor in the amazing progress PPI has made in bringing their “Educating through Technology” programs to the rural students in Tanzania.

Proceeds from this year’s event will go towards the Sazira Secondary School SPARC+ Lab Upgrade impacting 800+ students in rural Tanzania: an ambitious project needing $23,500. While this is significant, The Collegiate Churches of New York recently awarded Powering Potential a generous grant of $13,000 towards this goal.

PPI has an incredible event planned for their guests. Back by popular demand, Tanzanian dancers performing traditional dance led by Justa Lujwangana, CEO and founder of Curious on Tanzania will provide entertainment for the evening. A buffet will also feature authentic Tanzanian dishes based on menus from Taste of Tanzania by Miriam Malaquais. The author has donated twenty of her books for sale at the event with proceeds going to PPI.

Along with wine and soft drinks, a classic Tanzanian cocktail will be available to guests for a donation. The Dawa is a mixture of vodka, lime juice and honey. The word “dawa” is Swahili for medicine.

This year's event will also feature a Silent Auction with a variety of exciting items and services up for bidding.

Admission is $70 for early bird admission. Regular admission is $90 at the door.

Visit Poweringpotential.org to donate and reserve your space at this event.

Asante sana (thank you)!

Categories: FLOSS Research

Open Source Hong Kong Becomes an OSI Affiliate Member

Wed, 2019-05-22 12:25

PALO ALTO, Calif. - May 14, 2019 ​ - The Open Source Initiative (OSI), the founding organization of the open source software movement, is excited to announce the Affiliate Membership of the Open Source Hong Kong (OSHK). For ten years OSHK has worked across Asia to support open source communities, foster open source development, and increase the use of open source software, their recent OSI Membership highlights both organizations' desires to collaborate across communities.

“OSHK mission is promoting Open Source Software projects in Hong Kong and foster its development by connecting to the global open source community. In joining OSI as an Affiliate Member, OSHK connects with OSI, and other open source organizations, to support the promotion of open source,' said Sammy Fung, President of OSHK. "Open Source Software is not just about viewing the source code, it also guarantees the right to use the software, and modify it for our own use. By working together, I believe both organizations will be able to extend our reach and missions."

“We are excited to welcome OSHK as an OSI Affiliate Member,” said Molly de Blanc, OSI President. “The open source community truly is global, and their dedication to that idea is what inspires us as an organization. Our work for the future of open source is driven by that global community, and having the voices of OSHK in our affiliate membership helps us meet our goal in promoting and protecting open source and communities. We look forward to supporting their efforts and collaborating to help spread the message of open source even further.”

Currently, OSHK organizes the Hong Kong Open Source Conference (since 2013) and PyCon Hong Kong (beginning in 2015), with hopes to extend those event―and even add additional opportunities for open source communities to meet and collaborate. As a global organization the OSI is keen to help promote OSHK’s current events to both regional communities and our partners worldwide, as well as help develop new venues to raise awareness and adoption of open source software. As a growing segment in a large market, Asia promises to be a vital community in open source development and innovation. A partnership between OSI and OSHK will be critical in continued success.

The OSI Affiliate Member program allows non-profit and not-for-profit organizations to become OSI members. Full details of OSI Affiliate Membership and the names of the Affiliate Members are available on OSI's Affiliate Membership pages (www.opensource.org/affiliates) together with details for other non-profit and not-for profit organizations on how to join. Individuals can also become Members at www.opensource.org/join

About Open Source Hong Kong
Established in 2009, Open Source Hong Kong (OSHK) serves to foster and promote open source communities of and for developers, contributors, engineers, promoters, and users. OSHK develops and supports open source projects, and organizes conferences and events,within Hong Kong and across Asia, to encourage collaboration in the global open source community. To learn more about OSHK, visit: ​ https://opensource.hk/about/

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

OSI Board Evolution

Tue, 2019-05-14 10:42

I spent last week in New York at the annual new-inductees face-to-face Board meeting of the Open Source Initiative Board (pictured here – Christine Hall is also a member but was unable to join us). Having spent the last 11 years working on refactoring OSI for a new generation, I had advised the Board in advance that I intended to step down as President to make way for fresh blood. The Board elected Molly de Blanc as the new President and Josh Simmons as Vice President, with Hong Phuc Dang bravely volunteering to be CFO. I agreed to serve as Board Secretary until someone else feels ready to play that role – no later than next April when my term ends.


Simon Phipps, Elana Hashman, Pamela Chestek, Molly de Blanc, Faidon Liambotis, Chris Lamb, Hong Phuc Dang, Patrick Masson, Carol Smith (kneeling) Josh Simmons (kneeling)

The OSI I’m handing over to the new Board is very different to the one I first attended in 2008 (as an observer - I only joined the Board on leaving Sun in 2010). It is now elected rather than selected (albeit via an indirect mechanism to make California regulation easier to manage). The electors are over 60 affiliate organisations representing the majority of the world’s core open source developers and an ever growing community of individual members. OSI now has a viable income arising largely from a diverse range of around 30 sponsors. It now has a staff, including a full-time General Manager, Patrick Masson. It now has maintained systems for managing donations, lists and outreach. And there’s more been achieved – those are just stand-outs.

All together that means OSI has a proven foundation for the new Board to build upon. Already built on that foundation there are a postgraduate curriculum, a programme to advocate open source in the world of standards, a programme to equip schools with recycled PCs, working relationships with peer organisations like FSF and FSFE and more. There are many people responsible for all this change, too many to name here, and I thank them all.

People always look forward rather than back and there are still plenty of issues to deal with which are the new Board’s focus. We are already working to improve the license review process, for example. But I’m really pleased with what we have all achieved over the last decade at OSI (and how it matches my 2010 manifesto!) and am thrilled that there’s an energetic, more diverse and younger crew taking over.

Categories: FLOSS Research

April 2019 License-Review Summary

Mon, 2019-05-06 15:55

In April, the License-Review mailing list saw extensive debate on the Cryptographic Autonomy License, in particular:

  • its user data clause, and how it affects user freedom
  • obligations placed on the software operator
  • API copyright
  • strategic concerns for the OSI
  • public performance rights for software

The corresponding License-Discuss summary is online at https://opensource.org/LicenseDiscuss042019 and covers discussions about non-commercial licenses, license revocability, and LGPL/Apache compatibility.

Cryptographic Autonomy License

Van Lindberg submits his Cryptographic Autonomy License (CAL) to the review process. This is a network copyleft license, but with a broader scope than the AGPL. The CAL is motivated by ensuring user autonomy in blockchain-based applications. Lindberg has also written an in-depth blog post that serves as a rationale document. Last month, there had already been preliminary discussion about the license on the license-discuss list (see the summary).

Lindberg and Pamela Chestek summarize the core goals of the CAL:

  • that derivative works are handled in a copyleft manner
  • that any software offering the same API is under a compatible license
  • that user data is portable

Note: this summary uses the term “operator” to describe a user who runs the software so that other end users can interact with it.

Summary of Opinions

While the license presents welcome innovation in the network copyleft licensing space, there is also major criticism:

  • operators are subject to unacceptable restrictions regarding user data
  • it is not in OSI's interest to approve an API-copyleft license
  • the novel use of public performance is unclear, untested, unnecessary, and possibly ineffective

Bruce Perens does not recommend approval. Henrik Ingo [1,2] thinks that a “revised, less hazardous version of this license” could eventually get approved.

Meta

While Perens was eager to get his concerns heard early, Richard Fontana reminds that no urgency exists: as per the review process, new licenses get an initial 60 days of discussion before any decision. Simon Phipps adds that since Fontana's tenure as license committee director has ended, any review progress will be stalled until a replacement is appointed at the next board meeting.

License Purpose

Bruce Perens is concerned that the CAL goes beyond licensing software, but tries to establish some market. Perens suggests that the license's business purpose might better be reached through an ordinary contract.

Van Lindberg [1,2] responds that while the CAL is being drafted because of a business purpose, its terms are independent of that purpose. The terms only cover licensing of the software, under some conditions. Ultimately, every license has some purpose behind it. In the case of the CAL, the business purpose required a network copyleft license.

Perens argues that while other licenses may have their own purpose, they are not specific to some application. In contrast, the CAL seems specific to blockchain applications.

Lawful Interest in User Data

The CAL requires that operators must provide user data to which an end user has a lawful interest. For example, a user might have a ownership interest in the photos they upload to a photo storage service.

Bruce Perens [1,2,3] thinks that “lawful interest” is not sufficiently defined, and would require novel theories of data ownership: “There are opinions, and little case law.” This could even require disclosure to third parties if they establish a lawful interest.

Van Lindberg [1,2,3] responds that lawful interest is defined using known legal terms. The CAL does not grant new rights to user data: either the law recognizes some kind of data ownership or it does not. You can't end up with rights that you didn't already have.

Lindberg clarifies that the CAL references the GDPR not to define lawful interest, but to clarify how an operator must provide user data.

Perens points out: if the users already have a right to their data, why does the license need terms to that effect? Lindberg responds: “Just because I have ownership of data does not mean that you have an existing legal responsibility to give it to me. This is exactly the problem addressed by the CAL.”

User Freedom and Data

Van Lindberg [1,2] explains why he believes provisions about user data to be necessary. Preserving user freedom is core to Free Software. User data must be protected for that freedom to be effective:

The insight is that, increasingly, the data and the code are needed together to realize the program's function. Existing open source licenses, such as the GPLv3 family, recognize this and requires the provision of cryptographic keys that would prevent the execution of the code. The CAL recognizes that user freedom also includes the provision of the user's data so that the program functions completely and fully in a context of the user's choice.

[…] I may own my data. I may be able to get a copy of the source code. But […] unless I can use the software to process my own data, I also don't have effective freedom.

The CAL does not encumber or restrict user data, it just prevents it from being locked into a platform – similar to GPLv3's anti-Tivoization clause. Such a clause is necessary because hashchain applications offer new ways to lock down a program.

Bruce Perens is not convinced that end user freedom requires the disclosure of this user data. And the license must protect freedom not only for end users but also for operators, so why should it be acceptable to compel operator actions?

Pamela Chestek and Bruce Perens disagree with the comparison to the GPL's anti-Tivoization clause. It applies when a device with embedded software changes ownership, so that the new owner can install modified software on their hardware. In contrast, the CAL's user data provisions burden the operator of the software to provide access to user data. This is a fundamentally different kind of obligation.

Operator Obligations

Bruce Perens [1,2,3] is concerned that the operator's obligations regarding user data are unclear and excessive:

  • The CAL's requirements trigger on mere use of the software, which looks like an OSD #6 and #9 violation. How can forbidding or compelling an action not be a usage restriction?

  • It should be fine to just run software under an OSI-approved license, without having to read it. The CAL's user data requirements break this expectation. Operators have to hire a lawyer to understand the extent of their obligations. This is an unreasonable burden that limits their freedom.

  • The CAL affects data that is processed with the software.

Van Lindberg [1,2,3] counters:

  • The CAL's user data requirements are about as restrictive as the AGPL's source disclosure requirements: “The license compels an action by the licensee – to make the source code and data available. This is exactly the same type of action required under every copyleft license.”

  • The CAL does not extend to data: “No rights or obligations are created in any other work.”

  • The CAL does not restrict usage. It only requires user data to be provided to the extent that it is available. E.g. data may have to be decrypted for a user with a lawful interest, but the CAL is careful to not require disclosure of private keys.

  • The CAL only compels actions while the operator provides a service. They are free to stop at any time.

Lindberg appreciates the point that users should be able to run the software without reading the license. But with the CAL, the legal load for end users is still zero. Extra burdens are only placed on operators who want to provision the software as a service to others, which is the same scenario where the AGPL applies extra requirements. And anyway: “if you are providing services to others, you have already taken upon you substantial legal liability.”

Lindberg is amazed that Peren's examples boil down to preserving operator's freedom to lock down their user's data. “That freedom is definitely granted under some more permissive licenses, but preserving the rights of users is a core aspect of Free Software, which is the tradition addressed by the CAL.”

Henrik Ingo points out that open source licenses generally grant rights to users and shield them from legal risks. For example, restrictions on DRM are “a great example of protecting user rights”. Peren's objections seem to be problematic primarily with P2P software where end users simultaneously act as operators.

Solving Social Issues

Bruce Perens [1] agrees that data being hold hostage is a legitimate problem – but it is a social problem. OSI has previously rejected licenses that try to address social issues beyond the software. While OSI-approved licenses sometimes require disclosure of source code, also requiring disclosure of user data would be overreach.

Van Lindberg disagrees. The CAL is not in the same bucket of (non-free) licenses like 996 or JSON “do no evil”. The CAL tries to address an issue (user autonomy) “in the exact same way the GPL addresses the social issue of software freedom.”

API Copyright

Pamela Chestek [1,2,3] summarizes the CAL's relationship to API copyright: Any reimplementation of a CAL-covered API must be offered under the CAL or a compatible license. The CAL does not have a copyleft effect on software that merely uses/consumes the APIs. Assuming API copyright (Oracle v. Google) is overturned, the CAL will not be affected since the CAL is about public performance of APIs and not their reproduction. But without that precedent, how could other implementations be restricted?

Van Lindberg [1,2] confirms that Chestek's analysis is correct, but thinks the chances of API copyright being overturned are rather slim. Even then, CAL hooks into patent rights as a secondary means of enforcing copyleft.

Richard Fontana [1,2] notes that API reimplementations have to be open-sourced when their binaries are distributed or their interfaces are publicly performed. He criticizes the concept of “publicly performing an interface” as unclear, and thinks the relevant clause is written ambiguously. This launches a side discussion about the Oxford Comma.

Richard Fontana asks about the legal situation of API copyright in the EU under the 2012 SAS Institute Inc. v. World Programming Ltd. decision. Carlo Piana explains that the SAS ruling excludes language APIs, programming languages, and file formats from copyrightability in the EU.

Strategic Concerns on API Copyright

Richard Fontana warns that the CAL would be the first license to intentionally expand copyleft to APIs. Henrik Ingo is aghast at Lindberg's explanations: “this couldn't possibly be your intention”. They call some strategic concerns to attention.

Fontana believes that current community consensus is opposed to API copyleft. He sees “a deep-rooted policy against […] restrictive application of interface copyright in free software/open source […] that ought to be read into the OSD and our understanding of software freedom”. This “is supported by widespread hostility in the [community] to the result in Oracle v. Google” and the FSF's policy of opposing API copyrightability. While a license might acknowledge API copyrightability, it should only do so under highly permissive terms and not use it to impose copyleft requirements.

Henrik Ingo hopes the OSI “won't and can't approve of” such copyright-maximalist features. Instead, the open source community has an interest in promoting the view that interface implementations always or typically are fair use. Maybe, many years later APIs do become widely copyrighted. Only then would it be in the interest of the community to wield this power as well.

Ingo also mentions that right now, OSI approval of a license with API copyright elements would be highly undesirable as this could be used by Oracle lawyers as evidence that such views were widely accepted in the industry and open source community.

Van Lindberg understands the strategic objections, but doesn't think “it is an extension to use legal terminology and case law which already presumptively applies to software.”

Bruce Perens asks whether it is in OSI's interest to approve licenses that use public performance rights “for purposes other than requiring publication of the source code”.

There is also the matter of precedent. Perens notes the FSF (although disapproving of software public performance) did something similar with the AGPL, and the OSI eventually approved it. Pamela Chestek thinks this leads to “the understandable complaint that the OSI decisionmaking process can be unpredictable”, especially since no one has claimed that the CAL's API/public-performance aspects would violate the OSD.

Public Performance

Henrik Ingo [1,2] cautions that the “use of public performance in a software license is novel and untested.” This is risky for users. The license doesn't even need public performance rights to work but could use “legal methods that are more boring, but better tested and safer”. So for what reason should the license rely on public performance, other than maximizing its copyright power?

Van Lindberg [1,2] fundamentally disagrees here, and considers public performance key to the CAL. Practically speaking, the AGPL is the only available network copyleft license. But Lindberg found its network copyleft provisions lacking:

  • they do not trigger for unmodified versions
  • they can be gamed by using proxies
  • they are unsuitable to ensure user data access
  • they are unclear in a corporate context

Lindberg thinks [1,2] that it's better to use public performance – an established right in copyright law – than to define a unique term like “network interaction”. The use of public performance paired with some other definitions also clarifies corporate compliance.

Henrik Ingo agrees with Lindberg's analysis of the AGPL, and welcomes alternatives. Ingo criticizes the proxy loophole, and its GPL-like mindset that software will be executed as a single process on a single computer which accepts network connections.

However, Ingo vehemently disputes that public performance would be a solution. This is completely uncharted territory, and the CAL fails to bound its implications. Public performance “only adds uncertainty, but little practical value.”

The AGPL protects users by giving explicit and unlimited permission to run the program. Instead of restricting public performance, it uses an awkward construction that compels features of the software but not actions by the operator. Other licenses don't have to use that approach, but simple and clear legal terms help protect users. Perhaps the AGPL could be fixed by merely replacing “network interaction” with “interaction”.

Bruce Perens is confused why, if public performance rights are given, the AGPL went through the trouble of synthesizing a separate public performance-like right.

Pamela Chestek wonders how the CAL would work in the EU, where no equivalent public performance right might exist. Lukas Atkinson points to “communication to the public”, and suggests that the CAL could reference the WIPO treaty where it is defined.

Scott Peterson [1,2] is concerned that the CAL tries to introduce the notion that software interoperation could be the copyright holder's exclusive right. This would attract FUD. Actions that impact the interpretation of copyright law should be considered for their broader impact. Bruce Perens refers to Lindberg's argument that public performance is an existing right for software because software is a literary work.

McCoy Smith links to an article that argues that public performance rights do exist for software, but would not generally apply (Lothar Determann (2015): What Happens in the Cloud: Software as a Service and Copyrights. In: 29 Berkeley Tech. L.J. DOI: https://doi.org/10.15779/Z38DX3N).

Other points

Pamela Chestek provides a careful analysis of unclear language in the license.

Henrik Ingo is concerned that the anti-DRM provision might not be effective, which leads to some comparisons with the GPLv3 [1,2,3,4].

Categories: FLOSS Research

April 2019 License-Discuss Summary

Mon, 2019-05-06 15:55

In April, the License-Discuss mailing list:

  • talked about non-commercial licensing
  • discussed license revocability
  • answered a question about LGPL/Apache compatibility

The corresponding License-Review summary is online at https://opensource.org/LicenseReview042019 and covers extensive discussion about the Cryptographic Autonomy License.

International Licenses Redux

As proposed in December, Richard Fontana has updated the “International” license category of the OSI license list.

Non-Commercial doesn't compose

Chris Webber posts an essay about non-commercial licenses to the list, based on his experience working at Creative Commons.

Webber is “sad to see history repeat itself […] given the [recent] volume of submissions in favor some sort of noncommercial style license” (Note: like SSPL). Whereas Rob Myers joked that NC stands for No Community, Webber argues it represents “‘No Composition’, which is just as much or more of a threat”. Core points:

  • Defining (non-)commercial use is extremely difficult. See https://wiki.creativecommons.org/wiki/Defining_Noncommercial.

  • NC is asymmetric. “NC has the kind of appeal that a lottery does: it's very fun to think about participating when you imagine yourself as the recipient.”

  • NC feels like a minefield. If single NC licenses are already confusing, how would it feel if the whole system switched? For example, would a partially-NC Debian distribution be usable?

  • Different license users have opposed goals. “Libre Commoners” want to protect the commons, and want everyone to abide by the license. In contrast, “Proprietary Relicensors” want to prevent free riders in order to develop income. This is anti-community.

Webber concludes that “Noncommercial fails in its goals and it fails the community. It sounds nice when you think you'll be the only one on top, but it doesn't work, and it never will.”

Can a contributor take back open source code?

Antoine Thomas asks whether a contributor would be able to revoke/remove their contributions from a project, and how this would affect old versions of a project.

Kevin Fleming responds that legitimately provided open source licenses are not revocable, but that a project might honor a request out of courtesy.

Brendan Hickey points out that copyright law may provide special revocation rights, e.g. 17 USC §203. And even without revocation, a contributor could make life difficult for users.

Compatibility of LGPLv2.1 and Apache 2.0

Bryan Christ [1,2] asks whether Apache-covered software can link with LGPLv2.1 libraries and vice versa. The question is motivated by their incompatible patent clauses.

Bruce Perens [1,2,3] affirms that either direction of linking is fine: neither license imposes terms on the software it is linked with. But the LGPL does extend some terms onto the linked work in its entirety, which could be a problem e.g. with proprietary licenses that prohibit reverse engineering. While the Apache-2 patent clause is incompatible with the GPLv2, the LGPL is structured differently.

Bryan Christ notes that the ASF lists the LGPL as incompatible. Bruce Perens explains that the Apache Foundation excludes LGPL software from their own projects because the LGPL affects the larger work, but that the licenses themselves allow linking with each other.

McCoy Smith links to the FSF comment on the Apache license, but notes that it only discusses GPL and not LGPL.

Categories: FLOSS Research

Join Us In New York City

Thu, 2019-04-18 12:21

OSI members and affiliates are invited to join the OSI Board of Directors, local college and university student groups, and the broader New York City open source community to discuss "Careers in Open Source".

  • Open source jobs, what are they... where are they?
  • Finding and leveraging open source projects to expand your opportunities.
  • What companies and communities are looking for.
  • What you should look for, before accepting the job.
  • Getting the most out of your company to further your open source career.

If you're interested in a career in open source software, have some advice to offer, or just looking to network with peers, we hope you will join us.

Open Source Initiative Spring Meet-up and Mixer
Tuesday, May 7, 2019
6:00 PM to 9:00 PM
566 Fashion Ave Suite 504 · New York, NY
RSVP: https://www.meetup.com/Open-Source-NYC/events/258658427/

OSI Board Directors have broad backgrounds and experience, working in a variety of roles—Chief Open Source Officer, Chief Information Office, Chief Technology Officer, Open Source Program Manager, Community Manager, Developer, Architect, Engineer, Attorney—for both corporations and communities—Clojure Community, Cloud Native Computing Foundation, Debian Project, Free Software Foundation, Github, Google, Kubernetes Community, Microsoft, One Laptop Per Child, Open edX, Oracle, Python Software Foundation, Red Hat, Salesforce, Sun Microsystems , The Document Foundation, Wikimedia, Zalando... and many, many, more.

Photo credit: "NYCMeetUp.jpg" by Patrick Masson (CC BY 2.0) is a derivative of, "Jobs Board" by Malcolm Tredinnick (CC BY 2.0), via Flickr (https://www.flickr.com/photos/malcolmtredinnick/934039609/in/photostream/)

Categories: FLOSS Research

Powering Potential Expands to Peru

Tue, 2019-04-09 16:18
The Nainokanoka Secondary School
in the Ngorongoro District, Tanzania, May 2018

The Open Source Initiative’s first African Affiliate Member, Powering Potential Inc. (PPI), is pleased to announce the launch of their award-winning solar-powered Raspberry Pi computer labs in Peru. The pilot program builds on PPI's successes already enhancing education throughout rural Tanzania, Africa.

Over the past 13 years, PPI has installed 29 solar-powered systems, and 203 computers with servers, in 29 secondary schools across Tanzania. As a result, more than 23,000 students and teachers have been provided with direct access to educational materials and technology-training with minimal impact to the environment.

Neema Lyimo, PPI ICT Manager & installation team at
The Nainokanoka Secondary School, May 2018.

PPI created their Solar-Powered Access to Raspberry Computing (SPARC) installation model using Raspberry Pi computers loaded with an abundance of open source software, such as RACHEL from WorldPossible.org, and Kolibri from Learning Equality. Educational resources include Khan Academy videos, UNESCO textbooks, and Project Gutenberg literature with health and medical information.

Solar Panel Installation at
The Nainokanoka Secondary School, May 2018

A basic SPARC lab installation consists of five Raspberry Pi computers, two 85-watt panels, three 108Ah batteries, a 15 amp charge controller, a 350 watt inverter, and a lightning arrester system. A SPARC+ installation includes 15 more computers, additional solar panels, six new batteries, and a new charge controller. PPI also uses local vendors to work with school districts to provide solar power and additional equipment.

After installation, school district-selected teachers having a familiarity with technology are given a specialized three week “Train-the-Trainer” course. PPI prepares them to instruct tech literacy classes by learning networking, hardware, word-processing, database, file management, RACHEL maintenance, and email basics.

Project Team Meeting at the San Francisco School
in the Belen District of Iquitos, Peru with (l to r)
Anita Gil Avila, principal; Cledy Grandez Veintemilla,
Director of the Rosa de America private school;
V. Ena Haines, PPI Management Team; and Dana Rensi,
PPI Regional Director, Latin America, July 2017.

Currently, PPI’s pilot project is placing a SPARC lab in the Amazon region at the San Francisco Rio Itaya School, located in a low-income district of Iquitos, Peru. Leading this effort is Dana Rensi, PPI Regional Director, Latin America. She is a recipient of a Fulbright Distinguished Award in Teaching and an Educational Media Specialist in Ashland, Oregon. After being a Fulbright exchange teacher in Iquitos for a year, Rensi began working with V. Ena Haines from the PPI Management Team and is currently scheduled to be on site for five weeks this summer to establish the pilot. If successful, SPARC labs may also be expanded to other villages along the Amazon River.

The geographic isolation of this region in Peru is similar to rural Tanzania in terms of educational hurdles like a high turnover rate for teachers, limited resources and a lack of electricity. Iquitos, for example, is known as the largest city in the world that is accessible only by river or air, which makes technological progress challenging. The pilot installation is on the outskirts of Iquitos in Belén, one of thirteen districts of Peru’s Maynas Province known as “The Floating City.” Other villages along the Amazon River face the same accessibility problems coupled with regular seasonal flooding that has grown worse in some areas from climate change.

An external view of The San Francisco School
during seasonal flooding, March, 2019.

Rensi believes the SPARC lab installation could alter the game entirely for students there. “I came from teenage parents and a poor background. Education was my way out,” she explained during a recent interview. “They [the students] deserve an opportunity to learn no matter what circumstances they are born under or where.”

For this reason and more, PPI is actively seeking volunteers and sponsors for the pilot program in Peru alongside their continued efforts in Tanzania. They will also host a spring fundraiser celebrating their 10-year partnership with the Segal Family Foundation on Wednesday, June 5th from 6 to 8:30 p.m. at 39 West 29th Street in New York City to raise money for a major computer lab upgrade for the 800-student Sazira Secondary School near Lake Victoria in rural Tanzania.

To learn more or find out how you can help, visit Poweringpotential.org.

Categories: FLOSS Research

Pages