The Zephyr™ Project, is a Linux Foundation hosted Collaboration Project, an open source collaborative effort uniting leaders from across the industry to build a best-in-breed small, scalable, real-time operating system (RTOS) optimized for resource constrained devices, across multiple architectures.
About Zephyr Project
The Zephyr Project is governed by its member organizations as a Collaborative Project underneath the Linux Foundation. Read more about Zephyr Project governance.
What is Zephyr Project?
Zephyr™ Project, a Linux Foundation Collaboration Project, is a small, scalable real-time operating system for connected, resource constrained devices. The project is an open source collaborative effort uniting leaders from across the industry to build a best-in-breed real-time operating system (RTOS) optimized for resource constrained devices, across multiple architectures.
What makes the Zephyr project “open”?
The vision for the Zephyr Project is to create a truly community-based, open source RTOS that isn’t just called “open”, isn’t just licensed “open”, but actually lives and breathes the “open source way” (http://opensource.com/open-source-way and http://www.theopensourceway.org/). We want this project to be useful to the largest number of developers worldwide and in any industry that needs it. For that to happen, we are seeking discussion and active participation from a broad range of organizations. We want collaboration so that the Zephyr OS can evolve to meet the needs of its community.
The project has identified a core set of Maintainer roles – kernel, subsystem, architecture (ARM, x86, ARC, and others), security, and developer experience. As the Zephyr Project matures, the Maintainer roles will also grow to accommodate the need of managing the detailed subsystems, additional hardware support, and other features as well as documentation, advocacy, community management, financial management, and all the other trimmings needed for a healthy organization. We expect these roles to come from the member organizations, particularly those who have a proven track record of RTOS and small OS development. As with most open source developed projects, the Zephyr project seeks contributors willing to learn the codebase and contribute support via feedback, code, and feature development to evolve the software to become more modular and better suited to distributed and open development. Finally, the project seeks community managers with expertise in working and facilitating with open source development.
Contact us email@example.com now if you are interested in taking an active role.
What is the rationale for choosing the Apache 2.0 license?
here were three main factors influencing the decision to choose the current license model:
The licensing model needed to be permissive enough to allow the community and customers to use code, and contribute what they feel will be valuable back to the community.
We wanted an Open Source Initiative (OSI) approved, permissive license that is in broad use and is well known.
Apache 2.0 has a well understood patent grant
A permissive license gives the user the option to use proprietary extensions or share their code. Contributions are accepted without a Contributor License Agreement (CLA), and the expectation is that contributions will have the license captured as part of the headers in the code. IP compliance will be checked prior to acceptance into the codebase.
The project decided to use a well-known, permissive license to expand membership to a broad set of organizations including those who have not typically participated in open source development in the past. When we form the community, then we can re-open discussion about license through the governing board.
What is the project’s position on safety certification?
The project is exploring the prospects of safety certification, and the requirements associated with it. Safety certification requires a strict development process which could best be implemented with a parallel code base. This will require additional engineering resources and likely will require additional spending from the participating numbers to fund the certification. Given safety certification could save many organization’s significant time, there is likely financial advantage in sharing the cost of certifying the OS. The governing board continues to consider these factors and others before agreeing upon whether this is valued by all participating members.
To what extent is security integrated into the project and how ready is it for security audit?
Security audit, like safety certification, will be addressed in the Security WG, and final decisions approved through the Governing Board. The breadth of implementation will depend on guidance from the membership, community and steering committee members regarding readiness for any type of security audit and the resources assigned to advise on the security audit/ certifications of the code base. To find out more about how you can participate please contact: firstname.lastname@example.org
What boards are supported by Zephyr Project now?
Zephyr Project supports multiple architectures including ARC*, ARM*, Nios II, RISC-V, Tensillica, and x86. Details regarding functionality supported on the board can be found here.