IEEE.org     |     IEEE Xplore Digital Library     |     IEEE Standards     |     IEEE Spectrum     |     More Sites

Skip to content
M

manual

Project ID: 29

The IEEE Open Source Maintainers Manual.

IEEE Open Source Maintainers Manual

Contents

Copyright 2020, Maintainers Manual Authors
This manual is licensed to you under the Apache License, Version 2.0 (the "License").

1 Scope and Purpose

1.1 Welcome to IEEE Open Source

IEEE Standards Association (IEEE SA) supports Open Source as a model for technical innovation. IEEE SA has established its IEEE Open Source Platform ("the Platform") as a resource for the IEEE Open Source Community. The Platform provides a means of collaboration through the sharing of information and digital products with the clear intention of contributing to the success of an open source computer executable, hardware component or standard document. Open source allows access for multiple participants to inspect, modify, enhance, and utilize software, hardware, and other Open Source content. The Platform supports a variety of uses, including software incorporated in IEEE standards, projects focused on practical applications and humanitarian initiatives, individual education-related projects, and industry collaborative projects.

The Platform includes Gitlab/GitHub support, code repository procedures and support, license management support, and technical assistance, including support for testing and peer review, as well as links to self-help and training material.

IEEE offers many Technical Communities that offer opportunities for increased connection and awareness of developments. As used in this manual, the IEEE Open Source Community refers to all users with an authorized account on the Platform, all individuals and entities (e.g., governmental entities and corporations) with a valid IEEE open source Contributor License Agreement, and relevant members of IEEE volunteer governance and staff. If you have a free IEEE account and accept the Terms of Use and Contributors License Agreement (CLA), you can join the IEEE Open Source Community (details in Section 3).

This IEEE Open Source Maintainers Manual provides policies, guidelines, advice, and requirements for Project Leads, Maintainers, Contributors and other participants using the Platform or involved in an IEEE Open Source project (see section 2 for roles and responsibilities). This IEEE Open Source Maintainers Manual is also available as an Open Source project itself, with links to detailed procedures, templates for common files, sample guides, scripts, and various resources and materials that you can use to produce project-specific documentation and other resources for an Open Source project.

An Open Source project is the place on the Platform where you keep your files (repository), develop your end-product (contributions), plan your work or improve its quality (issues), describe its inner-workings (wiki) and release or publish completed working version of your project (project governance policies). The Platform supports several categories of projects:

  • IEEE Open Source Standards projects (results of the Open Source project will be incorporated as normative or informative content of an IEEE standard)
  • Joint IEEE projects (undertaken in collaboration with an external entity)
  • Official IEEE Open Source projects (Official IEEE releases are approved by IEEE OSCom)
  • Group projects (multiple participants, no specific organizational alignment with IEEE)
  • Individual projects (only one person involved in the project)

Projects are also classified by visibility:

  • Private: The Maintainer grants project access explicitly to each user. All users are Open Source Community members. The OSCom Community Manager and Platform administrators do have access.
  • Internal: The project can be accessed by any IEEE Open Source Community member.
  • Public: The project can be accessed without any authentication to view and download.

1.2 Useful resources

Sign in to the Maintainers community here:

https://opensource.ieee.org/users/sign_in

Access the online version of this IEEE Open Source Maintainers Manual here:

https://opensource.ieee.org/community/manual

Get help or report concerns with the Platform here:

Ethics and Compliance Helpline: Reports of violations, or concerns regarding potential violations, of IEEE Policies or the IEEE Code of Conduct can be filed anonymously through EthicsPoint:

📞 Call the 24-hour phone number: +1(888)359-6323

💻 Submit an online report: https://secure.ethicspoint.com/domain/en/report_custom.asp?clientid=20410

2 IEEE Open Source governance

2.1 Governance principles

In this manual, "shall" is used to indicate a mandatory requirement.

Project governance clarifies accountability for decision-making and enables conformance with applicable administrative, technical, security, and licensing requirements. Projects on the Platform are governed with various degrees of oversight and formality depending on their category, size, purpose, and incorporation into the IEEE brand.

Project governance may be provided by a single individual or organization; by a closed or open set of individuals or organizations; via a collaborative process among active contributors; through a consensus-driven process; or in some other manner. In all projects, it is necessary to identify all participants and to have clear definitions of who has the authority to take actions that affect the integrity of all or part of the source code, product releases, and the security of the Platform.

Project governance policies and procedures addresses questions such as:

  • Who is the Project Lead;
  • How Maintainers and Committers are determined, added, removed, and authorized;
  • Who may contribute to the project;
  • How merge requests are handled;
  • How and when releases are evaluated or reviewed; and
  • Who decides when a release can be made.

Projects other than individual projects can determine how they are organized (e.g., into teams or sub-projects) and set their own policies, goals, plans, schedules, and means of communications with project participants. The IEEE Open Source Community Manager (“Community Manager”) will provide samples of governance policies and procedures that can be used or adapted by Open Source projects. The governance policies and procedures of an Official IEEE Open Source project are made publicly available.

2.2 Governance organizations and leaders

The IEEE SA Board of Governors (BOG) has assigned responsibility for policies and overall management of the Platform to its Open Source Committee (OSCom). This committee reviews and approves applications for Official IEEE Open Source projects to use the Platform. The work of OSCom is governed by the IEEE SA Open Source Committee Operations Manual. Additional requirements for Maintainers of projects incorporated into IEEE standards are located in Section 6.5 of IEEE SA Standards Board Operations Manual.

Technical and administrative responsibility for use of the Platform is assigned to the Community Manager. In addition, the IEEE SA provides an Intellectual Property Rights Manager (“IPR Manager”), who is responsible for licensing and risk management, and other supporting staff. All of these staff, together with OSCom, are tasked with supporting users and are there to help as well as to fulfill their organizational and governance responsibilities.

The Community Manager is the primary point of contact for Project Leads and Maintainers. The Community Manager oversees the operation of the Platform and provides support on access to the Platform, tools that are part of the Platform or that can be used with it, release requirements and management, security, configuration management, and testing. If you are a Project Lead or are assigned as an IEEE Open Source Project Representative, you have a responsibility to respond to requests from the Community Manager in a timely manner. Project Leads and Maintainers should contact the Community Manager if they have questions about governance or to report security concerns.

2.3 Open Source project roles and responsibilities

Regardless of category, all Open Source projects have specific roles with defined responsibilities and privileges. In an individual project, the same person has all the roles and responsibilities.

The primary roles for projects are the following:

  • Project Lead
  • Maintainer
  • Committer
  • Contributor
  • User

Each IEEE Open Source project has a Project Lead and at least one Maintainer (who could be the same as the lead), as defined in the IEEE SA Open Source Committee Operations Manual. These are listed on the application for the Platform use as approved by OSCom. They continue in their roles for the life of the project, or until replaced.

Anyone who has the authority to contribute to the project is called a Contributor, and anyone with the authority to commit changes (e.g. approve pull requests or merge requests) is called a Committer. Users have the ability to view and download Open Source products for use outside the project or the Platform, consistent with the project's license and any additional applicable terms (e.g., terms for use of the IEEE Trademark).

Project Leads and Maintainers who can no longer carry out their responsibilities should inform the Community Manager via an email to contrib@ieee.org, and if possible suggest a replacement. Note that any new Maintainers shall be approved by the Project Lead and new Project Leads shall be approved by the Community Manager. Also, additional approval is required for appointment and replacements of Project Leads and Maintainers associated with IEEE Open Source Standards projects, see section 6.)

Responsibilities of Project Leads. Project Leads are responsible for the vitality, organization, development, evaluation, operation, security, and maintenance of an IEEE Open Source project. They act as the official point of communication with OSCom, the Community Manager, other parts of IEEE, other organizations, and the public for the projects they lead. Project Leads work closely with the Maintainer(s). Larger projects can choose to appoint or elect associate or alternate Project Leads and other coordinators, such as a communications coordinator or comments resolution lead.

Responsibilities of Maintainers. Maintainers have all the responsibilities and rights of Committers, plus the following responsibilities:

  • Ensuring that all required files, documentation, and notices are in place for their project on the Platform in accordance with this manual;
  • Administering the governance rules adopted by their project;
  • Maintaining control of the baseline source, forks, and releases during active development;
  • Designating Committers (in accordance with the project’s governance rules);
  • Responding in a timely manner to relevant communications and notifications posted on the Platform;
  • Responding to issues, merge requests, and other communications from the Project Lead and the Community Manager.

Responsibilities of Committers. Committers (including all Maintainers) are responsible for adhering to the governance rules for their project and the governance rules that apply to all IEEE Open Source projects. Committers are responsible for checking that contributions are properly marked to disclose intellectual property (see Section 8.3 for details).

Responsibilities of Contributors. Anyone who reviews and comments or posts any material on the Platform or in any project is a Contributor. Contributors represent that they have the right to allow use of the material on the Platform. Contributions to an IEEE Open Source project can only be made under the terms of an applicable and appropriate Contributor License Agreement (CLA) as described in Section 8 (Licensing Policies). CLAs may be submitted by an individual Contributor or by their organization. Contributors perform due diligence on their contributions.

Responsibilities of Users. The IEEE Open Source Platform makes available digital work for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by Users. Users are responsible for observing the copyright and licensing information in each open source file.

3 Account and group management

3.1 Using the IEEE Open Source Platform

Everyone using the Platform is required to obtain an IEEE account and to read and accept the IEEE Privacy Policy. There is no charge for an IEEE account. The registration page is available at https://www.ieee.org/profile/public/createwebaccount/showRegister.html

The privacy policy is available at

https://www.ieee.org/security-privacy.html

You will also need to accept the IEEE CLA license terms, as explained further in Section 8.

3.2 Requesting an Open Source project

Learn the features of a GitLab project here:

< https://opensource.ieee.org/help/user/project/index.md#projects-features>

To request a new Open Source project in the Platform, or to change a Project from one category to another, use the application form available here:

https://opensource.ieee.org/projects/new

You will need to enter the following information:

  • Project category;
  • Project title;
  • Project description (purpose);
  • The name and contact information (as stated in the IEEE account) of the Project Lead;
  • Name and contact information (IEEE account) of the Maintainer;
  • Selection of a single Open Source license and associated CLAs (see section 8, Licensing);
  • An indication of how the project will be governed;
  • A description of the relationship of the project to known Open Source;
  • Project visibility (public, internal, or private--see section 1);
  • If applicable, the associated PAR or IEEE standard(s);
  • Agreement to adhere to the Terms of Use and selected CLA

The project will be set up once reviewed and approved. Individual and Group projects are approved by the Community Manager. IEEE Official Projects are also reviewed and approved by OSCom.

All features are enabled for blank projects or when importing from Platform templates, but you can disable optional features afterward in the project settings.

On startup, your project will have the following files in its git Repository:

  • README - Project name, short description, license and CLA type, and other information taken from your application for the project as approved,
  • LICENSE - The official license of the project
  • NOTICES - Any additional appropriate legal notices that shall be included
  • AUTHORS - A list of copyright holders
  • CONTRIBUTORS - A list of contributors
  • SECURITY.md – The baseline security and critical vulnerability and exposure policy

These files shall remain at the topmost level of your Open Source project.

A sample file for project startup is here:

https://opensource.ieee.org/oscom/maintain/blob/master/content/templates/READEME_simple.md

If you are anticipating a complex open source effort, you may choose to organize your namespace as a Group with collaboration across multiple dependent projects. For example, you can have one dependent project open to public access, and other dependent projects where your development team works. Your Group can have nested subgroups as well. You can apply for a Group here:

https://opensource.ieee.org/groups/new

More help on getting started with a project, available elements, and using templates and sample pages is here:

https://opensource.ieee.org/help/user/project/pages/index.md#getting-started

4 Running a project

This section includes rules and advice for the Project Lead and Maintainer who are running an active project. For most projects on the Platform, this involves the use of Git, a distributed version control system used to coordinate collaborative work among project members. Comprehensive guidance for Maintainers learning and using Git can be found in the Pro Git book.

For additional guidance, email the Community Manager at contrib@ieee.org or chat with us in our MatterMost channel.

4.1 Delegating responsibility and access control

One of the first steps in setting up a project is for the Maintainer to grant access to all the expected Maintainers, Committers, and (for Private and Internal projects) Contributors and users. It is advisable that projects of all sizes have alternate Maintainers as a backup. The primary Maintainer should grant other Maintainers and Committers access to all relevant repositories.

Changes in Project Leads and the primary Maintainer should be promptly reported to the Community Manager and (as applicable) to the related IEEE organization. Projects without an active Project Lead or Maintainer for a period of more than 45 days may be shut down without further notice (see Section 7, Retiring a project).

4.2 Forking, branching, and merging

Branching and forking are two accepted development flows. Generally, established projects on the Platform use branching to collaborate on the same repository, and forking for distributed development, such as among subgroups. On the Platform, forks will be considered individual sub-projects: if you fork a group or official IEEE project, then you become by default the Maintainer of the new fork, and you become responsible for version control and version numbering within the new fork and its submodules. Any changes merged with the original project will be considered part of that project upon approval by its primary Maintainer.

More explanations here:

https://www.pluralsight.com/blog/software-development/the-definitive-guide-to-forks-and-branches-in-git

Projects can be set up to use automated continuous integration/continuous deployment (CI/CD). Consult the Community Manager for help with this.

Projects may choose to have Contributors sign off on specific contributions to indicate that due diligence or testing has been performed. Project governance documents should detail if approval is needed (and by whom) for committers merging the following:

  • New executable open source code;
  • Existing (third-party) open source code Contributions;
  • Non-executable text documentation (such as comments, images, specifications, requirements, user stories, user assistance, readme files); or
  • Patches provided by the Platform to be applied to your project.

More detailed information is here:

4.3 Licensing enforcement

The Maintainer is responsible for validation, scanning, and enforcement of CLAs (see Section 8 Licensing). This includes:

  • Making sure that applicable licenses and legal notices are included in the project files, i.e. checking that the correct copyright and license notice has been added to each source code file as a LICENSE file or as text within the source code file;
  • Adding required notices and disclaimers to your README file;
  • Responding promptly to alerts of unlicensed material and removing or quarantining it; and
  • Using the issue management system to update and close out reports of licensing issues.

4.4 Managing issues and problems

Maintainers are required to respond to issues that:

  • Involve security;
  • Pertain to compliance with applicable licenses, policies, or law;
  • Were assigned to a Maintainer by the Community Manager.

Maintainers can create or respond to merge requests on their own but should create issues for merge requests that would require changes in policy, entail significant implementation effort, or otherwise have a significant effect on users. Creating these issues allows feedback to be gathered from contributors. More information on creating and managing issues is here: https://opensource.ieee.org/help/user/project/issues/index.md.

4.5 Peer reviewing

The peer review process for Open Source projects permits peer reviewers to evaluate project information in collaboration with the project, subject to the governance rules adopted by project members. For IEEE Open Source projects and selected group projects, peer review is offered to add value and improve quality. Peer review can be undertaken at any point in project development, such as requirements review, software design, and pre-release code walkthroughs. It is an extension of the internal reviews that every large project should include and is valuable for smaller projects as well.

Open Source projects intentionally build on previous development and the work products are offered for continued creative development and exploitation. IEEE Open Source peer review is intended to affirm technical merit and identify areas needing improvement, and to suggest corrections in a positive way. It may also involve checking for bugs, missing features, and vulnerabilities with the aim of improving the product. It can also expose copyright infringement.

Open Source peer reviews can be requested from the Community Manager or arranged by the project team. Platform peer reviewers may be selected from a pool of Open Source community members and include those with experience in software design, coding, and testing and, when feasible, subject matter experts (SMEs) with knowledge of the relevant IEEE technical area and current related software resources. Peer review may be enabled by collaboration with IEEE Societies and Special Interest Groups which are knowledgeable in specific technical areas (e.g. hardware design and testing, energy and power, antennas, photonics, medical devices).

4.6 Publicizing and representing your project and the IEEE

Publicity about IEEE Open Source projects, especially project releases or experiences using the Platform, is encouraged.

All inquiries about specific projects should be referred to the Project Lead for response. Communications should make clear whether they represent an individual viewpoint or a position of the Open Source project. Governance documents for projects should designate a means of approval of public statements and a person (usually, the Project Lead) who is responsible for communications made in the name of the project.

Informal communications, or communications from group or individual projects that are not IEEE Official Open Source projects, shall not imply that the message is a formal position of IEEE, IEEE SA, or the IEEE Open Source community. Such communications shall not bear the logos of IEEE, IEEE SA, or any other part of IEEE such as an IEEE technical society, standards committee, or working group.

Communications from Official IEEE Open Source projects require approval of the Community Manager, who may consult with OSCom. If the project is associated with an IEEE technical group, the public communication should also be approved by the relevant officer of that group according to its policies.

Communications from joint Open Source projects between IEEE and another entity usually require approval of both entities.

Official IEEE Open Source Standards projects are considered subgroups of an IEEE Standards Committee or Working Group. As such, public statements also require approval of the Standards Committee.

5 Release Management

The governance document for your project indicates who determines when a release can be made. Project releases are designated by the Project as Official or unofficial. Unofficial releases are for internal or private use and are controlled by the Project and performed by the Maintainer.

Official releases are for public use and require review and coordination with the Community Manager. Official releases will undergo security code scans, be checked by the IPR Manager for compliance with licensing policies and procedures, and be cryptographically Signed by the Community Manager (OpenPGP signing).

A release package always includes a READ.ME file and a license file.

We use semantic versioning [SemVer] for versioning.

Official releases have a mirror copy archived in a private area. All previous Official releases remain in the Project archive.

More information on strategy for executing releases is here:

6 Standards Considerations

In addition to being approved by OSCom, projects that are incorporated into IEEE standards shall follow additional rules designed to ensure that technical decisions are made in accordance with the principles of open, consensus standards development and are overseen by the committee that developed or is developing the standard. IEEE Open Source Standards projects have special considerations for project management, initiation, project review and release, and maintenance of the Open Source product that is part of an IEEE standard. These projects, and the resulting open source product (e.g., software and related information) are governed by the IEEE SA Standards Board Bylaws https://standards.ieee.org/about/policies/bylaws/index.html

and IEEE SA Operations Manual section 6.5:

as well as this IEEE Open Source Maintainers Manual.

The complete IEEE standards development process is explained here:

6.1 Management responsibilities

IEEE Open Source Standards Projects operate as a subgroup of a Standards Committee or Working Group that develops the standard. The OS standard project is headed by an IEEE Open Source Project Lead, who is an elected or appointed Officer of the Standards Committee or Working Group responsible for the standard, and is a member of the IEEE Standards Association. The Open Source Project Lead can be the primary Maintainer for the project or name another person as the primary Maintainer, and can designate other Maintainers and members of the subgroup. The Standards Committee or WG decides if the Maintainers and Contributors to the project are required to be members of the WG or subgroup. Maintainers, Committers, and Contributors to the IEEE OS Standards project are not required to be members of the IEEE-SA.

All Maintainers, Committers, and Contributors (including people who comment on the OS material when the standard is being balloted) are required to agree to the selected CLA for the project.

6.2 Approval for project initiation

Open Source software associated with IEEE standards shall be developed on the Platform. Work on the IEEE Open Source Standards project cannot begin until the Project Authorization Request (PAR) for the standard itself is approved by the IEEE SASB and the request for an OS project is approved by the IEEE SA Open Source Committee. The PAR shall indicate that the project will include an OS product. If a group decides to add Open Source to a standard after the original PAR was approved (or not to include OS which had been proposed), a modified PAR shall be submitted for IEEE SA Standards Board approval.

6.3 Open source in an IEEE standard

Open source products associated with a standard are identified as Normative (required for conformance to the standard) or Informative (can be helpful in conforming to the standard, but not required). An example of Normative software in an IEEE standard is source code for an API that must be included in a product if the product is to conform to the standard. An example of Informative software in an IEEE standard is an open source reference implementation which developers are welcome to use but which is not required to be included in a product. As another example, consider software that computes a quantity X. If the standard says "quantity X shall be computed in the manner implemented in the software," then it is normative. If the standard says "an example of software that computes quantity X is given by the software," then it is informative.

Draft materials, including the OS, are generally not available outside the working group and the IEEE OS Standards project until the standard goes to IEEE Standards Association ballot. OS products associated with a draft (Unapproved) standard shall be marked Unapproved in the README file and code comments. The following notice is required:

This open source repository contains material that may be included-in or referenced by an unapproved draft of a proposed IEEE Standard. All material in this repository is subject to change. The material in this repository is presented "as is" and with all faults. Use of the material is at the sole risk of the user. IEEE specifically disclaims all warranties and representations with respect to all material contained in this repository and shall not be liable, under any theory, for any use of the material. Unapproved drafts of proposed IEEE standards must not be utilized for any conformance/compliance purposes.

The release package for an IEEE OS Standards Project (either for ballot or for publication) includes the software and documentation.

At a minimum, documentation shall include a README file that identifies the IEEE standard by name and number, copyright and license (CLA) information, approval status (i.e., unapproved, activation date, inactivation date) and the release number. Minimum documentation describes the purpose (use) of the software, with information (or a link to the information) on how to download and install the software, known errors, limitations, any help available for its use, and where to report errors or recommend changes. Code should be properly and generously commented.

6.4 Approval for review and release

Open source software associated with a standard - including its documentation - will be reviewed as part of the IEEE standards balloting processes and in a public review process as detailed in the IEEE SA Standards Board Operations Manual. Balloters and public reviewers receive access to a copy of the Open Source material, but not the right to modify the main copy of the source. Balloters and public reviewers can comment on the OS material as well as on any other part of the standard, using the IEEE SA myProject system. By commenting, balloters and reviewers are agreeing to a CLA and providing a license for their comments to be used as Contributions to the Open Source.

Comments on the Open Source material require responses (Dispositions: approved, revised, rejected), with Disposition Detail that gives the rationale for the revised and rejected responses. To help develop the disposition of those comments, the Project Lead or primary Maintainer should be part of the Comment Resolution Group for the standard. Changes agreed by the Working Group are entered as issues in the Platform system and tracked to completion. The Maintainer and Project Lead shall confirm that the agreed revisions are made before the comments disposition is released and the next recirculation ballot is held on the standard.

When the standard is approved by the IEEE SASB, the OS product, including documentation, is released at the same time as the standard is published. The release version should be the one that was approved on the final ballot, although editorial corrections can be made after the final ballot.

6.5 Maintenance of standards

Active IEEE Open Source Standards projects have to be associated with an approved, active PAR or an active IEEE Standard. If the PAR is withdrawn or the standard is inactivated, either the project will be inactivated or changed to another category, such as an IEEE Open Source project. Conversely, as long as an IEEE standard containing Open Source material is active, the associated IEEE Open Source Standards project shall be maintained by the Standards Committee or Working Group.

PARs generally allow four years for the completion of a standards project; if necessary, PAR extensions of a year or two can be requested.

No more than ten years after approval of an IEEE standard, it is required to be either inactivated or revised. It is possible to revise the text of a standard without changing the OS components, or to revise or update the OS components without changing the text of the standard.

If changes are needed in the approved OS product or the text part of the standard, they can be handled as a corrigenda (bug fixes); amendment (added or changed functions that do not affect a significant portion of the product), or a complete revision. All of these require approval of a revision PAR.

Open Source software artifacts associated with inactivated projects may be archived (removed from unauthorized access), transferred to IEEE-SA management as part of the inactivated standard, or transferred to an IEEE Open Source Standards project or another category of project.

7 Retiring a project

Projects may be terminated or deprecated and archived (inactivated) by the Community Manager if the project has:

  • No sign of activity (logons by Project Lead, Maintainer, Committer, or Contributor) for 180 days.
  • No identified Project Lead or Maintainer, or no response from the previous Project Lead and Maintainer, for 45 days.

Maintainers may archive Individual Projects or Group Projects at their discretion but should notify the Community Manager that their project has been or will be archived.

For Official IEEE Open Source Projects, a Maintainer can close a project with approval of the Project Lead or the group, as defined in the project governance. After notification and approval, the IEEE Open Source administrator will archive the project.

See Section 6.5 regarding inactivation of IEEE Open Source Standards projects.

The following actions are required to retire a project:

  • Update README file and CONTRIBUTING/GOVERNANCE files to state that the project is no longer actively maintained.
  • Email the Community Manager at contrib@ieee.org to have the project archived

8: IEEE Policies and Licensing

8.1 Use of the IEEE Open Source Platform

All users of the Platform are required to agree to the Terms of Use: https://opensource.ieee.org/community/cla/terms-of-use

IEEE reserves the right to remove content or take any action it deems appropriate if it determines that a user has not complied with the Terms of Use.

Overall IEEE policy regarding Open Source is found in section 6.5 of the IEEE SA Operations Manual. IEEE's detailed policies and procedures regarding copyrights, commercial terms and conditions, and patents are in clause 6 of the IEEE SA Operations Manual. These are all applicable to you and your project.

https://standards.ieee.org/about/policies/opman/sect6.html

By participating as a Project Lead, Maintainer, or Contributor to an IEEE Open Source project, or as a User of the Platform, you agree to conform to this IEEE Open Source Maintainers Manual, the IEEE SA Open Source Committee Operations Manual, and all applicable IEEE policies and procedures, including:

Be aware of IEEE policy on use of trademarked (proprietary) brand names in standards and open source products. Provisions involving business relations between buyer and seller such as guarantees, warranties, and other commercial terms and conditions shall not be included in an IEEE standard. Standards shall not endorse any particular product, service, or company. It generally is not acceptable to include manufacturer lists, service provider lists, or similar material in the text of an IEEE standard. Where a sole source exists for essential equipment, materials, or services necessary to comply with or to determine compliance with the standard, it is permissible to supply the name and address of the source in a footnote as long as the words "or the equivalent" are added to the reference. Standards and Open Source material shall avoid the appearance that they violate these rules.

8.2 Licensing and control of contributions

Licenses protect the rights of contributors and users of open source (e.g., software, hardware and procedures) including those who use open source in their derivative products. Users are granted rights by the project license(s).

All contributions to an IEEE Open Source Project shall be under the terms of an applicable and appropriate Contributor License Agreement (CLA). For Group and Official IEEE Open Source Projects, there are several licenses approved at this time, and CLAs that correspond to each license:

These differ in treatment of redistribution of software and patents. Each Project chooses a single license. This license also covers contributions of third-party material. Switching to a different license once the project is underway is not allowed and requires restarting a new project. You are encouraged to seek legal advice before selecting a license.

You will be assigned a CLA number. This number will identify your contributions. Please do not share your CLA number with others.

When submitting a CLA to the IEEE, you can choose to have that CLA be associated with: 1) a one-time submission, 2) a specific project, or 3) any project that requires that type of CLA. The CLA can be signed by an individual Contributor or by an entity representative to apply to individuals affiliated with that entity.

8.3 Tracking Contributor License Agreements in Open Source

Tracking of each contribution within a project is essential from a legal perspective and allows for the appropriate acknowledgement of each Contributor. A Committer should not assume that submissions from others can be freely used and distributed and are unencumbered by a license, patent, or trademark. Committers are obligated to exercise due diligence before incorporating and redistributing content received from others.

Contributors may provide contributions to a project, but such contributions do not exist in the repository or downloads unless they are accepted by a Committer. Maintainers and Committers have the obligation to control the content distributed in IEEE Open Source projects. Committers therefore have a responsibility to perform due diligence on any content they release. Maintainers have the additional capability to override Committer’s changes to the repositories or to directly commit code and therefore have a responsibility to perform due diligence on any content they release.

Due diligence is especially important when the contribution is deemed to be a "significant" one. A "significant" contribution is one that includes a substantial amount of code or content that introduces major new functionality into the code base, or any code or module that will be distributed under any license other than the project license.

Each Maintainer and Committer is required to take steps to ensure that intellectual property is properly received and can be tracked. Information about each contribution is typically maintained within Git commit records and the standard copyright headers contained within individual source files. Additions to project repositories are received as Git commits through the Platform to check that necessary licenses are granted and that there is a public, timestamped, and archived record of the submission.

For each contribution, the Committer and Maintainer shall check that:

  1. That the name and email address of the Contributor(s) are accurately captured;
  2. That the Contributor(s) have signed the IEEE Open Source Contributor License Agreement (CLA) and have a CLA number;
  3. That the Contributor has signed-off the Contribution, indicating that they are in compliance;

The Project and each Maintainer and Committer should allow sufficient time to complete due diligence on each contribution.

Repository content is only distributed through the Platform following the release management process defined in Section 5.

For cases where content redistributed from the Platform is not received as a contribution under the project license(s)- for example, when a Committer wishes to redistribute content maintained by another open source project- the Committer shall provide details of the package to the IPR Manager, who will initiate the intellectual property due diligence review.

8.4 Ethical considerations in your project

Anyone involved in the design and development of autonomous and intelligent systems should be educated, trained, and empowered to prioritize ethical considerations so that these technologies are advanced for the benefit of humanity. The IEEE Global Initiative for Ethical Considerations in Artificial Intelligence and Autonomous Systems provides material that supports this recommendation.

9 Security policies and procedures

9.1 Platform and project security responsibilities

The Community Manager is responsible for overall information security on the Platform. Administrators will regularly perform code scanning of all projects to identify vulnerabilities and malware. Official releases will be scanned before release. The Platform services include daily backups for disaster recovery of each active project.

Each project has a security contact. The default is the Maintainer. You may list the primary Maintainer or another Maintainer as the security contact for your project in your SECURITY.md page or you may provide the contact (or list of contacts) to the Community Manager to maintain privately.

Maintainers are responsible for promptly applying security patches provided by the Community Manager to their Projects.

Security issues will be tracked using the CVE (Common Vulnerabilities and Exposures) lists https://cve.mitre.org

9.2 Your security policy

All projects on the Platform shall have a SECURITY.md file in the root directory of their project's repository explaining their security policy. Following is a sample (default) SECURITY.md file.

TEMPLATE: SECURITY.md

You may choose to adapt this standard template or to construct your own security process documentation. In all cases, your documentation should be in line with the following process.

Security Reporting

Please report security vulnerabilities by filling out the following template:

  • PROJECT: A URL to project's repository

  • PUBLIC: Please let us know if this vulnerability has been made or discussed publicly already, and if so, please let us know where.

  • DESCRIPTION: Please provide precise description of the security vulnerability you have found with as much information as you can provide.

Please send the above information, together with any other information or evidence you feel is pertinent to: saopen-security@ieee.org

We ask that you keep the report confidential until we have made a public announcement.

You may request that the project provide you a patched release in advance of the public release announcement; however, we cannot promise that it will be provided to you.

The Community Manager will let you know within two business weeks whether action is being taken based on your report. If a corrective software release (patch) is appropriate, the release will be made before any public announcement. At a minimum the Community Manager will email you at the same time the public announcement is made.

9.3 Reporting and repairing critical vulnerability and exposures

Security vulnerabilities and concerns should be reported immediately by anyone associated with the Platform. Send your report to saopen-security@ieee.org. Security reports are confidential.

The Community Manager will contact the security contact listed by the Official IEEE Open Source Project and review the security vulnerability to determine if it is accepted or rejected. The Community Manager will notify the reporter if action is being taken based on the report. If a report is accepted the following protocol shall be followed:

  1. The Community Manager will determine if a CVE number should be obtained, and if so, IEEE shall obtain a CVE number.
  2. The Community Manager will determine an appropriate corrective action and communicate the status of the report within two weeks.
  3. The project will patch the vulnerability and stage a release and draft a short announcement that includes the CVE number, severity, and impact.
  4. The Community Manager will review the release and announcement and schedule a date and time for public release. At this time, your project may discuss any private disclosures you wish to make in advance of the public disclosure. An example is a report of the vulnerability. The Community Manager will only deny a request if it violates IEEE Policy or if the private disclosure would in effect be equivalent to making a public disclosure.
  5. The release shall be made as it normally would, but without disclosing that it is patching a security vulnerability.
  6. The release shall be timed so that a release announcement will be sent out immediately after the release. The announcement shall go out to all relevant security announcement mailing lists as well as any external security lists or portals the Community Manager deems appropriate (e.g., oss-security@lists.openwall.com).

If a report is accepted and this project is an IEEE Open Source Standards Project, then additional standards protocols will be followed:

  1. If the security-related fix is incorporated through an undated/unversioned release, then the above protocol suffices with the caveat that there may be additional mailing list or forums where the announcement will be posted.
  2. If the security-related fix is incorporated through a versioned reference, then it shall be determined if it is considered as a corrigenda or amendment. If it is a corrigenda, the above protocol shall be followed with the announcement timed to coincide with the release. If an amendment is required, then the above protocol shall be followed and then the amendment process shall be followed after the announcement is made. Until the amendment is approved, additional notices shall be placed on appropriate places warning users about the issue.

List of Abbreviations

BSD Berkeley Software Distribution

CLA Contributor License Agreement

CVE Common Vulnerabilities and Exposures

IEEE SA IEEE Standards Association

IPR Intellectual Property Rights

OpsMan Operations Manual

OS Open Source

OSCom Open Source Committee

PAR Project Authorization Request

PGP Pretty Good Privacy

SASB Standards Association Standards Board

SME Subject Matter Expert

LICENSE NOTICE

                             Apache License
                       Version 2.0, January 2004
                    http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

  1. Definitions.

    "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

    "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

    "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

    "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.

    "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

    "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

    "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

    "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

    "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."

    "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

  2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

  3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

  4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

    (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and

    (b) You must cause any modified files to carry prominent notices stating that You changed the files; and

    (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

    (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

    You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

  5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

  6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

  7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

  8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

  9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

APPENDIX: How to apply the Apache License to your work.

  To apply the Apache License to your work, attach the following
  boilerplate notice, with the fields enclosed by brackets "{}"
  replaced with your own identifying information. (Don't include
  the brackets!)  The text should be enclosed in the appropriate
  comment syntax for the file format. We also recommend that a
  file or class name and description of purpose be included on the
  same "printed page" as the copyright notice for easier
  identification within third-party archives.

Copyright 2019 OSCom

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.