Ensuring Openness Through and In Open Source Licensing

It simply may not be clear to those encountering open source for the first time the scope of the Open Source Definition, or the standards expected by the international open source community, when OSI approved licenses are applied. We’re here to help clear things up.

Some of the largest forces in business today—consumer-facing companies like Google and Facebook, business-facing companies like Salesforce and SUSE, companies outside the tech industry such as BMW, Capital One, and Zalando, even first-gen tech corporations like Microsoft and IBM—all increasingly depend on open source software. Governments too, including the European Union, France, India, the United Kingdom, the United States, and many others have discovered the benefits of open source software and development models. Successful collaborative development of software and infrastructure used by these organizations is enabled by the safe space created when they use their IP in a new ways… to ensure an environment for co-creation where the four essential freedoms of software are guaranteed.

Software distributed under an OSI Approved Open Source License offers much to businesses and governments: both as consumers and contributors. The software freedoms protected through open source licensing harnesses the power of distributed peer review and transparency of process driving economies through faster innovation, higher quality, better reliability, lower costs, and an end to vendor lock-in. The open source model also promotes increased security; because code in the public view will be exposed to extreme scrutiny, with problems found and fixed instead of kept secret until the wrong person discovers them. And last but not least, it’s a way that the little guys can get together, innovate and have a good chance at beating an established participant. Participating in open source projects and communities can build open standards as actual software, rather than paper documents. It’s a way for companies and individuals to collaborate around shared needs on a product that none alone could achieve or, in and of itself, does not constitute a key business differentiator.

Governments too recognize the value of open source as both a technology solution delivering value to the public they serve, as well as an approach for development returning tax-payer investments back to the society they represent.

A European Commission study of 2007 offered, “Open Source is key for ICT competitiveness”, yet, “Though FLOSS [Free/Libre Open Source Software] provides ample opportunities for Europe, it is threatened by increasing moves in some policy circles to support regulation that seeks to protect old business models of creative industries, making it harder to develop new ways of doing business.” [1]

The Open Source Initiative (OSI) has successfully addressed copyright licensing as a concrete expression of software freedom since its founding in 1998. But open source software licenses were always intended to go beyond copyright to deliver rights permission and rights protection for developers and users in multiple IP classes, both explicitly and implicitly. OSI has never approved a license that did not include robust rights to freely make, use and sell software, as required by the OSI’s key principles.

Open Source Includes Patents as well as Copyrights

An open source project and participating communities of practice have always expected that, if a project is “open source”, then they will receive all necessary rights associated with former and current participants to be licensed without further action. This expectation is guaranteed in the Open Source Definition (OSD), “The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties” [2].

The OSI has long explained that unrestricted licensing is essential to protect the software freedom inherent to open source software and the communities of practice that rely on unfettered use, modification and (re)distribution. The OSI has released multiple public comments, and recommended policy, on several issues that threaten open source software, including: open standards [3, 4], Digital Rights Management [5], FRAND [6], and software patents [7].

The OSI and the open source community have always treated patent licensing, as a precondition of implementation of a standard, as inherent in approved open source licenses, without any need for separate license grants. Even zero-fee licensing would be problematic, as it still might require (non-monetary) permissions from patent holders before the adoption and use of software, the antithesis of open source. Patent licensing is by definition bilateral—a one-off agreement between a licensor and licensee. Open source communities are by definition multi-lateral, where a single license affords concordance to all licensees. Any approach which includes separate patent licensing for specific users would undermine the multi-participant open source model, conflict with the OSD, and thus could never be interpreted as compliant with any OSI Approved Open Source License or the label “open source software”.

To be clear, of course, the decision to participate in an open source project is entirely voluntary. Companies may choose not to participate, and thus not to license their copyrights and patents. But if they participate in open source, then they must comply with these basic requirements for open source licensing.

Assertion of Patents Against Open Source Software Hinders Authentic Collaboration

Unrestricted collaboration, critical to authentic development in open source software communities, depends fundamentally on equality of participation and transparency of behavior. Organizations like Apache, OpenStack, Cloud Foundry and many others go to great lengths to ensure transparency and equality, and have rules that exclude the possibility of participation by those who attempt to breach either. Seen in the context of collaborative development and distribution, the assertion of a contributor’s patents against open source software is antithetical to open source approaches.

As a result, open source licensing terms prevent patent aggression and disadvantage those who attempt it. Far from being a sacrifice, this use of IP is arguably the dynamo of the technology industry, allowing startups and established corporations alike to rapidly climb upon the shoulders of earlier giants and deliver innovation. Web servers, smartphones, business automation, cloud computing and the sharing economy – to name just a few examples – all arise from the use of OSI Approved Open Source Licenses and would probably never have happened without it.

Open Source is a Defined Term

The OSI, as the steward of the OSD, is the community-recognized body for reviewing and approving licenses as OSD-conformant. The global software development and deployment community refers to software as “open source” when it is made available with source code under an OSI-approved IP license conveying the rights necessary to use, improve and share the software in a manner a given community considers appropriate. The OSD, and the OSI’s authority in certifying licenses, are internationally recognized by open source software projects (e.g. The Apache Foundation, The Linux Foundation, The Mozilla Foundation) [8] , corporations (e.g. Adobe, Dell/EMC, Facebook, Github, Google, HP, IBM, Microsoft) [9], and governments across the world [10].

There also are practical reasons why open source software needs to comply with the OSD and OSI’s approved licenses. Historically, where organizations have attempted to label some piece of software or another “open source” without applying an OSI-Approved Open Source License, the community consistently responds [11], confronting the offending organization [12, 13], emphasizing the consensus of the community [14], and demanding a resolution until alignment with community norms is again achieved [15]. In other words, it is not good business to falsely claim open source compliance.

All OSI-approved licenses share basic attributes defined in the OSD. In particular “mere use” is always permitted.

Approved Licenses, the OSI’s Process

A key goal of the OSI approval process is to allow those without access to corporate counsel to still participate confidently in open source collaborative development in service of their own use, improvement and sharing of the code. The OSI License Review Process ensures that licenses and software labeled as “open source” conforms to existing community norms and expectations. For that reason, all licenses must go through a public review process described below.

  • Ensure approved licenses conform to the Open Source Definition
  • Identify appropriate License Proliferation Category
  • Discourage vanity and duplicative Licenses
  • Ensure a thorough, transparent and timely review (e.g. within 60 days)

OSI’s “crystallisation of consensus” process for license review is overwhelmingly accepted in the community, serving as a nexus of trust and providing permission in advance for innovation. A license thus only becomes “approved” when open public review has reached consensus and the OSI Board has confirmed that consensus.

Individuals, corporations and SDOs may not assert or imply OSI Approved Open Source License status outside this process.

Ready to Help

OSI’s current and former Board has decades of experience in open source software projects and communities, the license approval process, and is aware of many modes of both success and failure related to licensing and community.

OSI is a donation-funded break-even 501(c)(3) with limited staff and a pro bono Board. OSI is nonetheless willing to correspond with any organization on open source matters, as well as help identify independent consultants.

To establish a corresponding relationship, please contact president@opensource.org

References

  1. Ghosh, Rishab Aiyer. The impact of Free/Libre/Open Source Software on innovation and competitiveness of the European Union, European Commission, 2007. Web. 25 October 2017. http://flossimpact.merit.unu.edu/
  2. OSI Board of Directors. The Open Source Definition. The Open Source Initiative, 1998. Web. 25 October 2017. https://opensource.org/osd
  3. OSI Board of Directors. Open Standards Requirement. The Open Source Initiative, 2006. Web. 25 October 2017. https://opensource.org/osr
  4. OSI Board of Directors. Open Standards Requirements for Software – Rationale. The Open Source Initiative, 2006. Web. 25 October 2017. https://opensource.org/osr-rationale
  5. OSI Board of Directors. Principles of DRM Nonaggression for Open Standards. The Open Source Initiative, 2016. Web. 25 October 2017. https://opensource.org/osr-drm
  6. OSI Board of Directors. FRAND and Open Standards. The Open Source Initiative, 2012. Web. 25 October 2017. https://opensource.org/node/616
  7. OSI Board of Directors. Search Results. The Open Source Initiative, 2017. Web. 25 October 2017. https://opensource.org/search/node/software%20patents
  8. OSI Board of Directors. List of OSI Affiliates. The Open Source Initiative, 2017. Web. 25 October 2017. https://opensource.org/affiliates/list
  9. OSI Board of Directors. OSI Corporate Sponsors & Support. The Open Source Initiative, 2017. Web. 25 October 2017. https://opensource.org/sponsors
  10. OSI Board of Directors. International Authority & Recognition. The Open Source Initiative, 2016. Web. 25 October 2017. https://opensource.org/authority#AustralianGov
  11. OSI Board of Directors. React to React. The Open Source Initiative, 2016. Web. 25 October 2017. https://opensource.org/node/862
  12. Mattmann, Chris A. RocksDB Integrations. The Apache Foundation, 2017. Web. 25 October 2017. https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16088663
  13. Mullenweg, Matt. On React and WordPress. MA.TT, 2017. Web. 25 October 2017. https://ma.tt/2017/09/on-react-and-wordpress/
  14. Multiple. December 2016 Archives by thread. The Open Source Initiative, 2016. Web. 25 October 2017. https://lists.opensource.org/pipermail/license-discuss/2016-December/thread.html#19600
  15. Wolff, Adam. Relicensing React, Jest, Flow, and Immutable.js. Facebook Code, 2017. Web. 25 October 2017. https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/

Image credit:
“openBlur.png,” ©Open Source Initiative, 2017, Attribution-ShareAlike 4.0 International (CC BY-SA 4.0), is a derivative (croped with blurring) of “Yes We’re Open.jpg“, ©Pernillan (Own work), 2017, via Wikimedia Commons and used with permission under an Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.