A key goal of some open collaboration efforts — whether source code or specification oriented — is to prevent technical ‘drift’ away from a core set of functions or interfaces. Projects seek a means to communicate — and know — that if a downstream product or open source project is held out as compatible with the project’s deliverable, that product or component is, in fact, compatible. Such compatibility strengthens the ecosystem by providing end-users with confidence that data and solutions from one environment can work in another conformant environment with minimal friction. It also provides product and solution providers a stable set of known interfaces they can depend on for their commercially supported offerings.
A trademark conformance program, which is one supporting program that the LF offers its projects, can be used to encourage conformance with the project’s code base or interfaces. Anyone can use the open source project code however they want — subject to the applicable open source license — but if a downstream solution wants to describe itself as conformant using the project’s conformance trademark, it must meet the project’s definition of “conformant.” Some communities choose to use words other than “conformant” including “certified”, “ready”, or “powered by” in association with commercial uses of the open source codebase. This is the approach that some Linux Foundation projects take to maintain compatibility and reduce fragmentation of code and interfaces.
Through this approach, we enable our projects to create flexible, custom-tailored conformance programs to meet the needs of their respective communities. In fact, our conformance programs can operate as open source projects themselves (see, for example, https://cncf.io/ck ). They incorporate a balance of interests from vendors, end-users, and contributors to the project and enable the community to define how the commercial ecosystem participants can leverage the use of the community’s mark.
Products or solutions that meet the requirements of the trademark conformance program can use the conformance program’s trademark. Those that do not meet its requirements, cannot. If the project community learns that someone is misusing a conformance program trademark — say using the mark to show compatibility without achieving all of the requirements of the conformance program — the community could work with the LF to take steps to advise them on how they can come into conformance with the program requirements, or discontinue their use of the trademark.
How Can an Open Project Establish a Conformance Trademark Program?
When our projects establish a conformance program, we recommend that they follow the following basic steps:
-
- Determine what you want the trademark to signify.
Are you interested in showing compatibility with a core segment of project code or interfaces? Do you want this mark to indicate backward compatibility? Do you want the mark to imply a certain level of ‘rigorousness’ of compatibility? How broad or narrow a focus of compatibility are you interested in (e.g., all of the code base, or a key portion)? Does a “compatible” solution necessarily need to use the underlying open source codebase at all, or just present a compatible interface?
This question is best addressed by involving interested stakeholders across business, marketing, and technical functions including discussions to resolve upon the intended meaning for the mark. Relevant stakeholders will likely include the project developers; downstream vendors who develop products based on the project’s outputs; and potential customers and end-users of those vendors.
A conformance program’s guiding star should be to ensure neutrality and objectivity in the conformance definition’s metrics. In order for an ecosystem to accept that the conformance trademark has relevance, it should be tied to a specific, articulated definition of what it does and doesn’t include. If the definition of conformance includes aspects of subjective evaluations by the project members, the result may be a perception that non-technical considerations such as favoritism were used as factors — and that the mark is not a reliable indicator of technical functionality. Objective criteria that are applied neutrally can help to avoid such a perception. In addition, the process by which the mark or requirements are defined should be specified and made known.
-
- Decide upon the specific requirements of conformance.
Once you have identified what you want the trademark to signify, you can craft a specific set of requirements necessary for a product to be able to use the conformance trademark. These requirements should also be developed within the community, and the development of these requirements is often closely tied to the work in item 1 above.
Additional questions to consider are:
-
-
- How long can a product or solution provider claim compatibility, and against what version(s) of the open source project? How many future versions will that conformance be valid for?
- Will the community create a test suite to provide an objective “pass / fail” determination for compatibility, or rely on more subjective considerations? (ideally, the answer should be the former)
- What triggers a requirement for a vendor to re-test and confirm that their solution remains conformant — every time a change is made, or after a set period of time, or only if/when complaints are received from the community, or something else?
-
-
- Determine how products and solutions will be qualified as meeting the requirements of the conformance program.
There are many approaches that our projects take with respect to qualifying products or solutions, and they range in expense from none/nominal to significant. A common approach is to publish the requirements and allow self-certification with the requirements via a registration page. The project would then publish a current list of all registrants so that end-users could — by way of the project’s web site — know that a particular vendor had self-certified their product as meeting the requirements. Depending on the nature of the project and the conformant vendors’ solutions, end-users themselves might be able to run the same set of self-tests on the solutions, to confirm compatibility for themselves. In some cases, end users may use the same tests to keep their internal teams conformant in their internal deployments. Tooling costs are also a consideration for projects in setting up automated testing systems.
Another approach is to engage with third-party test labs that will test whether submitted products or solutions, in fact, meet the conformance program requirements. This model may also be setup by publishing criteria or requirements that a test lab can follow to offer conformance program testing.
As you can imagine, the expense involved in contracting with third-party test labs can be significant. Many of our communities choose to lower barriers to entry for the ecosystem and keeping costs low is often a priority.
-
- Publish the requirements and begin operating the trademark conformance program.
Maintain the program’s requirements in a highly visible manner, and begin accepting registration applications! Keep a list of certified solutions on the project’s website or code repository.
In fact, the development and administration of the conformance program itself can even be run as an open source project (see: https://github.com/cncf/k8s-conformance).
Keep in mind that these programs will need to be maintained as well, especially as the project evolves and makes significant changes to its modules and interfaces. We often treat these conformance programs as their own open source collaboration that evolve with the project.
Example Programs Employed by Projects Supported by the Linux Foundation
A number of our projects have trademark conformance programs. These include:
1. Certified Kubernetes®
The Certified Kubernetes program is run by the Cloud Native Computing Foundation (CNCF) and is intended to ensure that open source code and vendor products based on Kubernetes support the core APIs that make up Kubernetes. Vendors that are interested in using the Certified Kubernetes mark are required to submit conformance testing results to CNCF for review and approval. Additional information on the program can be found here: https://www.cncf.io/certification/software-conformance/.
2. ODPi Egeria Conformant™
The ODPi Egeria Conformance program is intended to ensure both consistency and alignment with the interfaces developed by the ODPi Egeria project. The participation form and the terms and conditions of the program can be found here: https://www.odpi.org/projects/egeria/conformance.
3. OPNFV Verification Program (OVP)™
Created through collaboration between OPNFV and ONAP, two projects within LF Networking, OVP focuses on compliance, validation, performance, and interoperability testing for commercial NFVI (cloud platform infrastructure) implementations and VNFs (telco cloud applications). This conformance program is used to indicate that an OVP-branded product or solution:
-
-
- Supports key behaviors, functions, and related APIs and packaging requirements of the OPNFV and ONAP release
- Implements defined NFV functions
- Supports end-to-end life cycle management interoperability among an NFVI/VIM built on the conformant products, applications designed to run on that infrastructure, and ONAP
- Is a good candidate for internal testing by the operator in their own specific environment
-
Products or solutions that meet these requirements are then able to use the OPNFV VerifiedTM brand under the appropriate usage guidelines. The program supports both self-certification by vendors and testing via approved third-party labs. Detailed information on OVP can be found here: https://www.lfnetworking.org/ovp/
4. Powered by OpenDaylight®
OpenDaylight is one of the technical code projects within our LF Networking umbrella which has a “Powered by OpenDaylight” conformance trademark program. Products using the mark are required to implement certain core sections of the open source code with the current release of OpenDaylight or the prior two releases. A FAQ on the program can be found here: https://www.opendaylight.org/ecosystem-solutions/for-solution-providers/powered-by-faq-page
The registration page for a company interested in applying to use the “Powered by…” trademark can be found here: https://www.opendaylight.org/ecosystem-solutions/for-solution-providers/powered-by-reg-form
