Posts

In its role as an ISO PAS submitter, JDF and LF now can move from idea to code, to standard, to an internationally recognized standard, vastly improving the reach and availability of the technologies created by our amazing communities.

Introduction

This week, we are proud to announce that the Joint Development Foundation (JDF), which became part of the Linux Foundation family in 2019, has been accepted as an ISO/IEC JTC 1 PAS (“Publicly Available Specification”) Submitter. The OpenChain Specification is the first specification submitted for JTC 1 review and recognition as an international standard. 

The JDF was formed to simplify the process of creating new technical specification collaboration efforts.  Standards and specifications are vitally important for the creation or advancement of new technologies, ensuring that the resulting products are well defined, provide predictable performance and that different implementations can interoperate with one another.  

Why the Linux Foundation cares about standards

The Linux Foundation itself was formed out of the merger of the Free Standards Group, which maintained the LSB (“Linux Standards Base”) and the Open Source Development Labs. Open standards and open source software have been part of the mission from the very beginning.

Standards play a role in everyone’s life. Think about the things you touch every day, as simple as a power plug, the USB connector on your phone or laptop, or the WiFi that you use in your business and your home to connect your mobile devices wirelessly. All of these devices need to be able to interoperate with each other.

A pragmatic and sensible approach to solving interoperability issues would be to create open source software projects everyone can use. However, there are cases where open source software alone will not solve all the implementation challenges that open standards can achieve. 

Open source software in and of itself may not solve particular situations where there will be many implementations in many different device or delivery models (e.g., video codecs or 3D printer designs with many software design tools and many hardware printers and scanners). Still, in other cases, that fragmentation is due to different device capabilities, implementation details, or limitations that open source software cannot resolve alone.

The design and capacities of many things are defined by industry stakeholders as a standard so that every plug and device is interoperable and capable of the same connectivity.  Every country in the world has its own national standards bodies that define the standards it deems necessary, from power transmission, radio spectrum, food safety, and others.

Not all standards bodies are national standards bodies, with standards organizations coming in many shapes and sizes. Many standards are developed by industry-specific organizations that have a common set of technical objectives and are seeking a common set of use cases, a shared set of key design and performance criteria, and a common test specification to ensure interoperability.  

For the Linux Foundation, our collaborations can range in size from small to large, but their impact can extend internationally. There is not a Linux kernel per country or an Open Container Initiative specification per country, and so on. The world is dependent on our communities.

Like Linux Foundation source code projects, JDF standards and specification development projects can range from small, industry-specific efforts, to large multi-industry collaborations. And it is the JDF’’s goal to serve these various communities.  By obtaining PAS status, JDF can help specification and standards communities ranging from the smallest collaborations through to international standardization.   

How Open Standards differ from Open Source projects

Open standards are best defined as specifications made available to the public, which are developed and maintained via an inclusive, collaborative, transparent, and consensus-driven process. Open standards facilitate interoperability and data exchange among different products or services and are intended for widespread adoption.

Open source software is defined by the OSI’s Open Source Definition. In practice, we generally care more about communities that form to work on open source software in a public, transparent collaboration where the code evolves over time to address new use cases, features, requirements, and gaps.  

Sustainable open source software communities also see continuous improvements as bugs and security issues are identified and fixed. Open source code is typically created as a collaborative effort in which programmers improve upon the code and often share the changes among the programming community for such projects. At a high level, open source licenses allow users the freedom to use, modify, and distribute the source code without requiring any further permission.

So, for example, software such as the Linux kernel is open source software in an open community, whereas the IETF curates open standards that enable the world to connect through an open Internet.

Another excellent example of how standards come into play across different hardware and software platforms are web servers. There are many web server platforms, both open source, and proprietary — such as Apache’s and Microsoft’s IIS. Some are optimized for speed, others for large deployments, some for low power devices, and for other applications. But as long as they can all speak HTTP (and other standards), they can still all communicate across the spectrum of devices.

The process of creating standards

Standards bodies are usually formed by industry stakeholders to support the activities needed to develop a specific solution to a common problem. The resulting solution is generally referred to as a specification, a blueprint for building an implementation of a solution to the problem. In some cases, the same group may also create an open source implementation, but the implementation will be specific to a set of use cases and requirements.

A standards body is the legal organization often created to provide a neutral home to the collaboration, including financial and legal support, guardrails against antitrust issues, managing copyrights and other intellectual property terms that might bear on the specification. Many will say the most important role of a standards body is to provide a neutral governance model that enables inclusive participation from all parties, where no one organization controls the specification.

The challenges in creating specifications

For something as crucial as a specification, the process of creating a specification setting body can be complicated.  

And even when the participants are aligned, the devil is always in the details. The negotiations to establish a new standards organization often involves hundreds of hours of lawyer time and a method of negotiating the nuances of the working rules and the license terms for copyrights, patents, and trademarks related to the effort.  The entire process can take many months — and it’s a requisite precursor in most cases to the technical contributors getting started. So before anyone knows what the output will be, or if it will even work, many organizations collectively invest thousands to millions of dollars on months of negotiations that delay the start.

Once the mass negotiation is done, the legal entity needs to file for non-profit status, set up bank accounts, set up accounting, finance, and HR operations, collect fees from its members, and file its taxes, just like a commercial company. These activities need to occur even if all the initiating organizations are 100% aligned on the need for the specification. Once that is all done, the engineers can get together to develop a specification, often a year after the initial idea was created.

The JDF was founded to make the entire process of forming a new standards body faster, and remove the negotiations. The JDF has created a set of default terms that reflect industry best practices and proven widely accepted legal terms.  By providing a choice of pre-existing, industry-accepted terms, JDF replaces custom negotiation with a “check the box” model. This model adopts best practices while giving flexibility through a few commonly known choices to the founders about essential terms such as copyright, intellectual property licensing, source code licensing, and governance structures.  It also allows JDF projects to be customized to meet the needs of the community, without resorting to time-consuming line-by-line negotiations.  

And once those terms are in place, the new project is formed as an entity under the non-profit JDF.  In combination with world-class operational support programs, a new project can get started in a matter of days, with resources ready to go, rather than the months to the years-long process required to form a traditional standards body. The cost of this effort is so low that a specification project can be established without any funding needed for the creation or ongoing entity management.

In essence, the JDF provides a “standards organization in a box.” Just pick a few menu options, give the effort a name and off you go creating specifications. 

The net impact of the JDF process means that companies with the need to collaborate can form the project, define the technical scope and begin inviting engineers to contribute to the project in a matter of days with minimal friction.

Internationally recognized standards through the ISO/IEC JTC 1 PAS process

One method of recognizing international standards is via the ISO/IEC JTC 1 PAS (Publicly Available Specification) Process. Once accepted through this process, the specification is recognized as an international standard. 

ISO is an independent, non-governmental international organization with a membership of 164 national standards bodies, and its standards are among the most universally recognized and accepted throughout the world.  

The IEC (International Electrotechnical Commission) is the world’s leading organization for the preparation and publication of International Standards for all electrical, electronic, and related technologies. 

ISO and IEC joined together to create ISO/IEC JTC 1, which is the international group dedicated to developing worldwide Information and Technology (ICT) standards. JTC 1 has been responsible for many key IT standards — including video compression technology and programming languages, among many others.

The Publicly Available Specification (“PAS”) process was created by a collaboration between ISO/IEC JTC 1 to allow for transposition of technical specifications from recognized standards bodies, which will enable them to become an ISO/IEC recognized standard. 

PAS Submitters must first be approved after a review of an extensive set of criteria by the external standards bodies. Once approved, a PAS Submitter may put forward some of its specifications (the publicly available specifications, PAS) to JTC 1 for national body approval and thereby international recognition. 

And once ISO/IEC JTC 1 approves a PAS submission, it becomes an international standard.

The JDF’s acceptance as a PAS Submitter is vital to the industry because it reduces friction on the path from great ideas, to well-formed technical specifications, to international recognition of the best of those specifications. JDF has the responsibility for ensuring that the process of creating the specifications is rigorous, inclusive, and conforms to the quality standards set by ISO/IEC JTC 1. The benefit of having a professionally managed standards organization like JDF is that we help ensure those requirements are met.  

And it also means that JDF provides a capability that few other organizations can — a path for communities to start from a small collaboration and grow to become an international standard.  

Understanding the OpenChain specification, our first PAS submission

The OpenChain Specification identifies the key requirements of a quality open source compliance program. It is intended to foster a software supply chain where open source is delivered with trusted and consistent compliance information. It provides a clear way to achieve effective management of open source for software supply chain participants, such that the requirements and associated collateral are developed collaboratively and openly by representatives from the software supply chain, open source community, and academia.

“The OpenChain Project is a clear example of cooperative development to share a common challenge,” says Shane Coughlan, OpenChain General Manager. “Hundreds of companies have come together, shared knowledge, and built a clear, focused industry standard based on their experience. The result is a compact but effective standard suitable for companies of all sizes in all markets.”

The OpenChain Specification has been in the market since late 2016 and has seen increasingly broad adoption to-date. The OpenChain participants include national user groups exceeding 100 participants and over 3,500 subscribers to the primary communication channel mailing list. ISO/IEC JTC 1 recognition will help to guide the evolution of the specification from de facto to de jure standard, and in the process assist procurement, sales, and other departments around the world adopt and manage OpenChain specification-related activities easily.

Conclusion

With its recognition as a PAS Submitter, JDF now provides the broadest range of support to standards communities – from small collaborations to those seeking international standards. As part of the Linux Foundation family, JDF is providing communities with new ways to collaborate.  

By affiliating with JDF, the Linux Foundation ecosystem can benefit from the support and expertise to move open source specifications into an open standards-track, that empowers engineers and developers to collaborate in the creation of a specification and standard. By using this new submissions process, they can take their standard a step further to achieve international recognition. Conversely, the importance of the JDF joining the Linux Foundation family is significant because it is in alignment with the organization’s overall goal of furthering the commitment to neutral governance and alignment of open source software and open standards.

— Jim Zemlin, Executive Director, The Linux Foundation

Communication is one of the seven essential elements to ensure the success of open source license compliance activities. And it’s not enough to communicate compliance policies and processes with executive leadership, managers, engineers, and other employees. Companies must also develop external messaging for the developer communities of the open source projects they use in their products.

Below are some recommendations, based on The Linux Foundation’s e-book Open Source Compliance in the Enterprise, for some of the best ways to communicate open source license compliance both internally and externally.

Internal Communication

Companies need internal compliance communication to ensure that employees are aware of what is involved when they include open source in a commercial software portfolio. You also want to ensure that employees are educated about the company’s compliance policies, processes, and guidelines. Internal communications can take any of several forms:

  • Email communication providing executive support and of open source compliance activities

  • Formal training mandated for all employees working with open source software

  • Brown-bag open source and compliance seminars to bring additional compliance awareness and promote active discussion

  • An internal open source portal to host the company’s compliance policies and procedures, open source related publications and presentations, mailing lists, and a discussion forum related to open source and compliance

  • A company-wide open source newsletter, usually sent every other month or on quarterly basis, to raise awareness of open source compliance

External Communication

Companies also need external compliance communications to ensure that the open source community is aware of their efforts to meet the license obligations of the open source software they are using in their products.

External communications can take several forms:

• Website dedicated to distributing open source software for the purpose of compliance

• Outreach and support of open source organizations which help the company build relationships with open source organizations, understand the roles of these organizations, and contribute to their efforts where it makes sense

• Participation in open source events and conferences. This can be at various levels ranging from sponsoring an event, to contributing presentations and publications, or simply sending developers to attend and meet open source developers and foster new relationships with open source community members.

Open Source Compliance

Read the other articles in this series:

The 7 Elements of an Open Source Management Program: Strategy and Process

The 7 Elements of an Open Source Management Program: Teams and Tools

How and Why to do Open Source Compliance Training at Your Company

Basic Rules to Streamline Open Source Compliance For Software Development

The following is adapted from Open Source Compliance in the Enterprise by Ibrahim Haddad, PhD.

In the past few years, several cases of non-compliance with open source licenses have made their way to the public eye. Increasingly, the legal disposition towards non-compliance has lessons to teach open source professionals. Here are my four top takeaways, gleaned from the years I’ve worked in open source.

1. Ensure Compliance Prior to Product Shipment/Service Launch

The most important lesson of non-compliance cases has been that the companies involved ultimately had to comply with the terms of the license(s) in question, and the costs of addressing the problem after the fact has categorically exceeded those of basic compliance. Therefore, it is really a smart idea to ensure compliance before a product ships or a service launches.

It is important to acknowledge that compliance is not just a legal department exercise. All facets of the company must be involved in ensuring proper compliance and contributing to correct open source consumption and, when necessary, redistribution.

This involvement includes establishing and maintaining consistent compliance policies and procedures as well as ensuring that the licenses of all the software components in use (proprietary, third-party, and open source) can co-exist before shipment or deployment.

To that effect, companies need to implement an end-to-end open source management infrastructure that will allow them to:

• Identify all open source used in products, presented in services, and/or used internally

• Perform architectural reviews to verify if and how open source license obligations are extending to proprietary and third-party software components

• Collect the applicable open source licenses for review by the legal department

• Develop open source use and distribution policies and procedures

• Mitigate risks through architecture design and engineering practices

2. Non-Compliance is Expensive

Most of the public cases related to non-compliance have involved GPL source code. Those disputes reached a settlement agreement that included one or more of these terms:

• Take necessary action to become compliant

• Appoint a Compliance Officer to monitor and ensure compliance

• Notify previous recipients of the product that the product contains open source software and inform them of their rights with respect to that software

• Publish licensing notice on company website

• Provide additional notices in product publications

• Make available the source code including any modifications applied to it (specific to the GPL/LGPL family of licenses)

• Cease binary distribution of the open source software in question until it has released complete corresponding source code or make it available to the specific clients affected by the non-compliance

• In some cases, pay an undisclosed amount of financial consideration to the plaintiffs

Furthermore, the companies whose compliance has been successfully challenged have incurred costs that included:

• Discovery and diligence costs in response to the compliance inquiry, where the company had to investigate the alleged inquiry and perform due diligence on the source code in question

• Outside and in-house legal costs

• Damage to brand, reputation, and credibility

In almost all cases, the failure to comply with open source license obligations has also resulted in public embarrassment, negative press, and damaged relations with the open source community.

3. Relationships Matter

For companies using open source software in their commercial products, it is recommended to develop and maintain a good relationship with the members of the open source communities that create and sustain the open source code they consume. The communities of open source projects expect companies to honor the licenses of the open source software they include in their products. Taking steps in this direction, combined with an open and honest relationship, is very valuable.

4. Training is Important

Training is an essential building block in a compliance program, to ensure that employees have a good understanding of the policies governing the use of open source software. All personnel involved with software need to understand the company’s policies and procedures. Companies often provide such education through formal and informal training sessions.

Learn more in the free “Compliance Basics for Developers” course from The Linux Foundation.

Read the other articles in the series:

An Introduction to Open Source Compliance in the Enterprise

Open Compliance in the Enterprise: Why Have an Open Source Compliance Program?

Open Source Compliance in the Enterprise: Benefits and Risks

3 Common Open Source IP Compliance Failures and How to Avoid Them

Enterprises using open source code in infrastructure must understand both the risks and benefits of community-developed software. Professional open source management is a discipline that focuses on minimizing risk and delivering the benefits of open source software as efficiently as possible.

For successful open source management, enterprises must adopt clear strategies, well-defined policies, and efficient processes. Nobody gets all this right the first time, so it’s also important to review and audit your policies for continuous improvement. Additionally, successful open source initiatives for enterprise IT must provide real ROI in acquisition, integration, and management.

To examine these concepts in detail, The Linux Foundation is hosting a free webinar called “Open Source Strategy for Enterprise IT” on Thursday, Jan. 26 at 10:00 a.m. Pacific time. In this webinar, presented by Bill Weinberg, Sr. Director and Analyst, Open Source Strategy, and Greg Olson, Sr. Director, Open Source Consulting Services, you will learn about:

  • The elements of enterprise-level open source strategy

  • Using OSS as a secret weapon for innovation and differentiation

  • Current and new use cases for OSS

  • Attracting and retaining talent with OSS use and contribution

  • OSS security and compliance in the enterprise context

In a previous webinar (called “When Open Source Becomes Mission Critical”), Weinberg and Olson covered other topics related to managing open source software and talked specifically about the risks of under-management. Such risks include legal factors involving non-compliance of licenses, operational risks involving the ability of the software to meet enterprise needs over time, and security-related risks involving vulnerabilities that companies must stay on top of.

Weinberg said the moral here is that managing open source software shouldn’t be an afterthought; it should be part and parcel of using and integrating open source software.

Learn more in the free webinar “Open Source Strategy for Enterprise IT, on Thursday, January 26, at 10:00 AM Pacific time. Register Now>>