├── w3c.json ├── policies ├── README.md ├── fees.html ├── fsa-deed.html ├── cla-deed.html ├── guidelines-for-evaluating-individual-requests-to-participate-in-a-group.html ├── reqs.html ├── compare.html ├── summary.html ├── final.html ├── cla.html ├── bg_agreement.html └── process.html ├── README.md ├── proposals ├── process-enhancements.md ├── handling-ambiguity.md ├── cg-lifecycle.md ├── continued-participation.md ├── spec-lifecycle.md └── cg-process.md └── transfer-considerations.md /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "repo-type": "process", 3 | "contacts": "dontcallmedom", 4 | "group": 49289 5 | } 6 | -------------------------------------------------------------------------------- /policies/README.md: -------------------------------------------------------------------------------- 1 | The W3C Team uses this repository to reflect the history of policy files associated with Community and Business Groups. 2 | 3 | Note: As of October 2023, the W3C Team has not automated the process of ensuring consistency between this repo and files on w3.org. In case of discrepancy, please rely on the policies on w3.org. 4 | -------------------------------------------------------------------------------- /policies/fees.html: -------------------------------------------------------------------------------- 1 | W3C Business Group FeesWhile there are no fees to participate in a Community Group, non-Members pay an annual fee to participate in a Business Group according to this schedule: 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 |
TypeAnnual fee (USD)Annual fee (JPY)Annual fee (EUR)Annual fee (CNY)
Large non-Member Organization10,0001,100,000890068,000
Small non-Member Organization2000220,000150013,500
Unaffiliated individual30032,0002252000
W3C Member0000
44 |
45 | Note: These rates are effective 01 Oct 2020 for any new Members or renewals after that date. 46 | 47 | A "Large" organization is one whose annual gross revenue, as measured by the most recent audited statement, is greater than or equal to 50M USD. A "Small" organization is one with revenues less than that threshold, with more than one employee. 48 | 49 | For non-Member Organizations that join a Business Group, any number of their employees may participate in that group. 50 | 51 | If an Organization is itself a consortium, user society, or otherwise has members or sponsors, the Organization may assign any number of paid staff to a Business Group and one other individual not employed by the Organization (or more at the discretion of the Community Development Lead). 52 | 53 | An unaffiliated individual is one that has no significant employment relationship with an Organization. An unaffiliated individual is not considered an "Organization" under this policy. 54 | 55 | W3C Members must not assign non-employee representatives to a Business Group. 56 | 57 | After joining a group, non-Member participants sign the Business Group Participation Agreement, which addresses payments, renewal, termination, and other administrative matters. -------------------------------------------------------------------------------- /policies/fsa-deed.html: -------------------------------------------------------------------------------- 1 | W3C Community Final Specification Agreement (FSA) DeedEach Community and Business Group Final Specification includes this copyright statement: 2 |
3 | 4 | Copyright © [YEAR(S)] the Contributors to the [Name/Version Information] Specification, published by the W3C [Name of Community/Business Group] under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available.
5 | Note for Editors: For markup boilerplate, please see the Report Requirements. 6 |

Summary of Key License Terms

7 | The W3C Community Final Specification Agreement (FSA) expresses the full agreement between the parties that signed the agreement ("I" in the license agreement) and you ("you" in the license agreement). The following is a handy, human-readable expression of key terms of the FSA. This summary is not the actual agreement. This summary has no legal value or effect and its contents do not appear in the actual agreement. 8 |

What Signers Give under the Final Specification Agreement (FSA)

9 | Under the FSA, signers give everyone: 10 | 14 |

What the Community Gets

15 | The community is free to: 16 | 21 |

Use of Trademark

22 | See section 4 of the agreement. 23 |

Representations, Warranties and Disclaimers

24 | See section 9 of the agreement. -------------------------------------------------------------------------------- /policies/cla-deed.html: -------------------------------------------------------------------------------- 1 | W3C Community Contributor License Agreement (CLA) DeedEach Community and Business Group draft Specification includes this copyright statement: 2 |
3 | 4 | Copyright © [Date] the Contributors to the [Name/Version Information] Specification, published by the W3C [Name of Community/Business Group] under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.
5 | Note for Editors: For markup boilerplate, please see the Report Requirements. 6 |

Summary of Key License Terms

7 | The W3C Community Contributor License Agreement (CLA) expresses the full agreement between the contributors ("I" in the license agreement) and you ("you" in the license agreement). The following is a handy, human-readable expression of key terms of the CLA. This summary is not the actual agreement. This summary has no legal value or effect and its contents do not appear in the actual agreement. 8 |

What Contributors Give under the CLA

9 | Under the CLA, each contributor gives everyone: 10 | 14 | Note: Contributors have a 45-day opt-out from the date they contribute material; see section 5 of the agreement. 15 |

What the Community Gets

16 | The community is free to: 17 | 22 |

Use of Trademark

23 | See section 4 of the agreement. 24 |

Representations, Warranties and Disclaimers

25 | See section 11 of the agreement. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Community Group Program Repository 2 | 3 | This repository, associated with the [W3C Community Group Program CG](https://www.w3.org/groups/cg/council/) is used to track issues and improvements with the W3C Community Groups and Business Groups program. 4 | 5 | The W3C Team uses this repository to reflect the history and status of policy files that govern Community and Business Groups. 6 | 7 | ## Revamp (started in 2024) 8 | 9 | In April 2024 the W3C staff who manage the Community Group program began a project to enhance it. 10 | 11 | Community Groups have become a credential entry point to Web standardization, both at W3C and at other organizations such as the WHATWG, IETF, and ECMA. Through discussions with many Community Groups and the overall W3C community, the staff has identified several objectives: 12 | 13 | * When a CG specification has traction and there is community support for standardization, lower barriers to advancing to standardization (at W3C or elsewhere). 14 | * When a CG is just getting started, provide additional support and training for Chairs to help them run the group successfully. 15 | * At all times, foster clear communication about the status of CG specifications and do more to help the community distinguish community-driven work from W3C's standardization activities. 16 | 17 | We anticipate that each objective may involve multiple changes. For 18 | example, lowering barriers to standardization may involve changes to 19 | the participation model, changes to IPR policies, and changes to other 20 | elements of W3C process. 21 | 22 | Changes may affect a number of aspects of the program: 23 | 24 | * CG-specific Process and IPR agreements 25 | * Integration of general W3C policies (e.g., code of conduct, competition guidance) 26 | * Training materials 27 | * Tooling support 28 | * Visual design and information architecture 29 | 30 | The group's [issues related to revamp 2024](https://github.com/w3c/cg-program/labels/revamp-2024) capture some of the themes and challenges that we have surfaced through our discussions. 31 | 32 | ### Proposals 33 | 34 | To address the above objectives we are developing a series of proposals, listed here. 35 | 36 | * [CG Specification Lifecycle](proposals/spec-lifecycle.md) 37 | * [Community Group Lifecycle](proposals/cg-lifecycle.md) 38 | * [Handling standardization ambiguity](proposals/handling-ambiguity.md) 39 | * [Support for continued participation in a Working Group by CG contributors](proposals/continued-participation.md) 40 | * [CG Process](proposals/cg-process.md) 41 | 42 | ### Links to presentations 43 | 44 | * [AC Meeting 2025](https://www.w3.org/2025/Talks/cg-enhancements-ac2025.pdf) (Member-confidential) 45 | * [Breakout at AC Meeting 2025](https://www.w3.org/2025/Talks/cg-breakout-ac2025.pdf) (Member-confidential) 46 | * [Breakout at TPAC 2024](https://www.w3.org/2024/Talks/TPAC/cg-breakout/) 47 | -------------------------------------------------------------------------------- /proposals/process-enhancements.md: -------------------------------------------------------------------------------- 1 | # Process Enhancements for CG Specifications with Traction 2 | Status: As of July 2025, the staff is no longer pursuing this proposal. 3 | 4 | ## Background 5 | 6 | Once a specification has gained traction, we anticipate that implementers and users of the specification will naturally start to 7 | prefer stability due to their investments. A group may still want to change a specification based on implementation or deployment experience, but we expect that group consensus will increasingly favor stability. 8 | 9 | Many CGs in practice (such as WICG, Web Assembly, Social Web, and GPU for the Web, and Solid) adjust their decision-making processes once a specification gains traction. 10 | 11 | We are seeking generally to lower barriers to advance to standardization, but in practice there is often a delay between when a 12 | specification has gained traction and when a W3C Working Group or other SDO has taken up the specification. 13 | 14 | For that reason, we propose to create guidelines for CGs that have specifications with traction. 15 | 16 | **Note**: Although we want Specifications with traction to advance to standardization, we also want to be able to charter a Working Group in some cases where there is not traction, for example: 17 | 18 | * The context is such that it is important to charter a standardization activity, even without one specification with traction. 19 | * The community has not been able to converge and there are multiple competing proposals (full specifications or feature definitions) on the table. In this case, a Working Group (with its additional process supports) could help the community pursue a harmonized Specification. 20 | 21 | ## Guidelines 22 | 23 | **Note:** This is an outline for discussion. 24 | 25 | ### Definition of Traction 26 | 27 | > A Specification with Traction is one that fulfills any of the following criteria: 28 | > * It is implemented in at least two products (e.g., browser engines) with large-scale distribution in the Specification ecosystem 29 | > * Significant changes to it would disrupt the ecosystem of the Specification (e.g., in terms of adoption or references). 30 | 31 | ### Decision processes once a Specification has traction 32 | 33 | * Chairs should seek to make decisions when there is consensus. 34 | * Chairs or editors determine and record consensus decisions through the GitHub repo for the specification. 35 | * Chairs should ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favor or discriminate against any group participant or their employer. 36 | 37 | ### Handling formal objections 38 | 39 | * Where participants do not reach consensus and substantial disagreement remains (e.g., the group is divided), the Editors 40 | should continue with their preference. 41 | * The issue should be recorded publicly as decided without consensus. 42 | * Participants may choose to develop an alternative branch of the specification to seek support from implementers or 43 | the community. 44 | * If a specification advances to standardization, the issues decided without consensus should be brought to the attention 45 | of the standards group. 46 | 47 | ### Appeals 48 | 49 | Note: This may need to go in a revised CG Process. 50 | 51 | * When a participant wishes to contest a **process matter**, they may escalate to the Community Development Lead, who will work with the participant and Chairs to understand the situation and pursue a fair resolution. 52 | * There is no formal appeal path outside a Community Group for **technical decisions** made by the Community Group. 53 | 54 | ## Implementation Notes 55 | 56 | * The [CG Charter template](https://w3c.github.io/cg-charter/CGCharter.html) includes relevant provisions, but these should be reviewed. 57 | -------------------------------------------------------------------------------- /policies/guidelines-for-evaluating-individual-requests-to-participate-in-a-group.html: -------------------------------------------------------------------------------- 1 | Guidelines for Evaluating Individual Requests to Participate in a GroupPeople who participate in W3C Community or Business Groups fall into one of the following groups: 2 | 3 | * People affiliated with a W3C Member organization. 4 | * People affiliated with an organization that is not a W3C Member. 5 | * People with no affiliation to any organization. 6 | * People who are part of the W3C staff. 7 | 8 | For information about how to join a group as an employee of a W3C Member, please see our FAQ on Member participation. 9 | 10 | The information below applies only to people who are affiliated with an organization that is not a W3C Member and people with no affiliation to any organization. 11 | 12 | The W3C Community and Business Group policies seek a balance between individual participation and organizational legal commitments (e.g., the Community Contributor License Agreement (CLA)). While W3C has a preference for organizational, rather than individual patent and copyright commitments, people may request to participate without representing their organization's legal interests. The W3C Staff has the sole discretion to approve such requests, typically after some discussion with the person who has made the request. After such discussion, several outcomes are possible: 13 | 18 | If you have any questions about participation as an individual, please write to team-community-process@w3.org. 19 |

Considerations

20 | Below are some of the considerations the W3C Staff apply when evaluating requests to join as an individual. 21 | 32 | The W3C Staff may request additional context from the person who made the request and may ask other individuals (e.g., the Chair) for additional context. 33 | -------------------------------------------------------------------------------- /proposals/handling-ambiguity.md: -------------------------------------------------------------------------------- 1 | # Handling standardization ambiguity 2 | 3 | Status: This is a proposal for discussion; it does not yet represent consensus. 4 | 5 | The [About page for CGs](https://www.w3.org/community/about/) begins: 6 | 7 | > W3C has created Community and Business Groups to meet the needs of a growing community of Web stakeholders. Community Groups enable anyone to socialize their ideas for the Web at the W3C for possible future standardization. 8 | 9 | The program thus sets an expectation that when a CG incubates a specification, they should have an eye towards future standardization. The CG program is meant to support technology development up to a point (and for an extended period of time), but not to be a permanent home. 10 | 11 | Community Groups frequently find themselves in one of three situations: 12 | 13 | * A specification has traction and advances to either a W3C Working Group or another SDO. 14 | * A specification does not gain traction and is retired without standardization. 15 | * A specification has gained some traction, but the group has no clear standardization expectation or plan. 16 | 17 | In the first two cases the work on the Community Group specification can be stopped, either because the group has succeeded in transitioning to standardization, or it is clear that they are ready to stop the effort. 18 | 19 | In this document we discuss ideas to support groups in the third situation, called here "standardization ambiguity." 20 | 21 | ## Why this matters 22 | 23 | Once a CG specification has gained some traction, it is common for the community to require some time to complete its work and line up support before transitioning the work to a standardization group. In some cases, however, a specification may have traction for years but does not advance to standardization. Reasons include: 24 | 25 | * There is vibrant ecosystem for this technology (so work on it shouldn't be stopped), but may not fulfil all standardization readiness expectations (e.g., only one implementation with no clear commitment from other implementers and the group is waiting for a second implementation). 26 | * There are a large number of implementations of this specification, and for that reason, the community does not see the value in making the effort to go through standardization. 27 | * The group may wish to advance to standardization, but has questions (where? how?) or is concerned about obstacles. 28 | 29 | When CG specifications with traction do not advance for an extended period of time, this creates problems for the broader community as well as W3C specifically. For instance, CG specifications for the Web that gain traction but that do not undergo the quality controls of the W3C Process may harm the Web ecosystem by facilitating the emergence (and possibly wide adoption) of worse solutions than what a standardization process would produce. CG specifications with traction may also create confusion in the market about whether they are standards. That confusion can harm W3C's reputation, and could lead to other risks as well. 30 | 31 | ## Proposed approach 32 | 33 | Once the staff is aware that a specification has traction (e.g., through communication with the chairs or via tooling that is being developed), the staff organizes a chat with the CG chairs. 34 | 35 | In the case of standardization ambiguity, the staff will focus on the question: **does the group want to advance to standardization**? 36 | 37 | **If the answer is "yes" or "maybe,"** then the staff will work with the group to understand opportunities and obstacles and create a standardization plan. The standardization plan mostly needs to set expectations, including that the group may require time before advancing to standardization (e.g., while awaiting a second implementation). In short, as long as the group wants to advance to standardization and demonstrates clear intention, the staff will support that effort (and leave the group open). Depending on the situation, the staff may invest energy into encouraging the group to pursue standardization. A Community Group that wishes to develop support among the Membership as part of making the case for standardization should reach out to the [Exploration Interest Group](https://www.w3.org/groups/ig/exploration/) (see also their [issues list](https://github.com/w3c/exploration-ig/issues)). 38 | 39 | **If the answer is "no"** (or the staff believes the answer is "no" based on circumstances such as inactivity or lack of response) then the staff will support the group's migration to another venue. A community can, for example, set up its own Web site and tooling at low cost to support its ongoing activities, under its own control. Once migrated, the staff will archive the group (and link to the new venue). In short, once the Community Group program no longer adds value to a community beyond Web hosting, the staff will assist the group's transition to another venue. 40 | 41 | -------------------------------------------------------------------------------- /policies/reqs.html: -------------------------------------------------------------------------------- 1 | Report RequirementsThis page provides the details behind the requirements of the Community and Business Group Process related to deliverables. 2 |

Formal Identification

3 | W3C provides a means for each group Chair to publish and thereby designate the group's Reports (as defined in the CLA and FSA). These reports are listed on the group's home page. 4 | 5 | Final Reports must be published on the W3C Web site. This can be achieved through mechanisms available on GitHub. 6 |

Style Sheets

7 | ReSpec is a widely used tool at W3C for creating specifications, and it includes four style sheets (for draft and final reports, both for Community and Business Groups); set specStatus in the configuration accordingly (e.g., specStatus = CG-DRAFT). Several documents using ReSpec are linked from the reports page. Please note that ReSpec is not required, but is a useful option for editors. 8 |

Logos

9 | To avoid confusion about standardization status, a Community Group Report must not use a W3C organization logo. 10 | 11 | A Community Group Report must use the appropriate W3C Community Group logo (draft or final) in the upper left corner of the document. These logos are included automatically when using ReSpec. 12 |

Name and Date

13 | The report must include: 14 | 18 |

Relation to Standards Track

19 | The report must not cause confusion about its status, in particular with respect to W3C Technical Reports. For example, reports must not suggest that they are standards or on the standards-track. 20 |

Copyright

21 | The copyright statement to include at the top of each report 22 | varies depending on whether the document is a draft or final report. In the boilerplate below please replace YEAR(s) (with a single year or range), the name of the report, the URI to the group's home page ("groupname"), and the Group Name. 23 | 24 | For draft reports, based on the CLA Deed, please use this markup (adjustments for HTML5 ok): 25 |
<p>Copyright © YEAR(S) the Contributors to the REPORT NAME/VERSION, published by the  <a href="https://www.w3.org/community/grouphome/">Group Name</a> under the <a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a>. A human-readable <a href="https://www.w3.org/community/about/agreements/cla-deed/">summary</a> is available.
26 | </p>
27 | 
28 | For final reports, based on the FSA Deed, please use this markup (adjustments for HTML5 ok): 29 |
<p>Copyright © YEAR(S) the Contributors to the REPORT NAME/VERSION, published by the  <a href="https://www.w3.org/community/grouphome/">Group Name</a> under the <a href="https://www.w3.org/community/about/agreements/final/">W3C Community Final Specification Agreement (FSA)</a>. A human-readable <a href="https://www.w3.org/community/about/agreements/fsa-deed/">summary</a> is available.
30 | </p>
31 | 
32 |

Boilerplate

33 | In the boilerplate below please replace the URI to the group's home page ("groupname"), and the Group Name. 34 | 35 | The following paragraph appears at the top of each draft report: 36 |
<p>This report was published by the <a href="https://www.w3.org/community/grouphome/">Group Name</a>. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a> there is a limited opt-out and other conditions apply. Learn more about <a href="https://www.w3.org/community/">W3C Community and Business Groups</a>.</p>
37 | 
38 | The following paragraph appears at the top of each final report: 39 |
<p>This report was published by the <a href="https://www.w3.org/community/grouphome/">Group Name</a>. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href="https://www.w3.org/community/about/agreements/final/">W3C Community Final Specification Agreement (FSA)</a> other conditions apply. Learn more about <a href="https://www.w3.org/community/">W3C Community and Business Groups</a>.</p>
40 | 
41 |

Patent Licensing Commitments

42 | Readers should be able to find the contribution history easily from the report. Per the Community Group process, the contribution history must be archived permanently on the W3C Web site. 43 | 44 | For final reports, W3C maintains information about which participants have signed the Final Specification Agreement and which have not. A final report must refer to the page maintained by W3C. 45 |

Privacy Policy

46 | Reports must not violate the W3C Privacy Policy. In practical terms, this means not tracking report users via a third party system. 47 | 48 |

Additional Requirements for Final Reports

49 | 50 |

A version of the Specification must be available in English.

51 |

The content of the Specification snapshot at that URL must not change other than for minor editorial changes.

52 | 53 | 54 | -------------------------------------------------------------------------------- /policies/compare.html: -------------------------------------------------------------------------------- 1 | The following table compares some key elements of W3C group types. See also original design goals for the Community and Business Groups program. 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 |
WorkingInterestCommunityBusiness
ScopeDetermined by CharterDetermined by CharterDetermined by scope statementApplication of technology to business context; requirements and use cases; input to standards process
Creation processTeam proposes charter to MembershipTeam proposes charter to MembershipProposal is completeProposal is complete and management approves resource allocation
DurationLimited by charter, may be extendedLimited by charter, may be extendedUnlimitedUnlimited
Primary DeliverableStandards-track and supportingNote (which may become a Statement)Community Group Report (e.g., a technology innovation from a small set of developers). Community Groups Reports are not standards-track documents.Business Group Report (e.g., use cases or requirements of a particular industry to be provided as input to a Working Group). Business Groups Reports are not standards-track documents.
Staff ContactYesYesNot generally; but see W3C Team support for W3C Community GroupsConsulting role (e.g., share expertise, but not likely to attend meetings regularly). But determined by W3C Management on a case-by-case basis.
Other Staff InteractionsBackground support and coordinationBackground support and coordination (for some)Monitoring, Outreach 55 |
    56 |
  • One project review with Team annually
  • 57 |
  • Light Monitoring by staff
  • 58 |
  • Liaison role as needed
  • 59 |
  • Communications of final reports through W3C news channels and to W3C Membership
  • 60 |
61 |
Fee to participate or organizeMembership or Invited Expert (no fee)Membership or Invited Expert (no fee)NoneAnnual fees for non-Members
Confidentiality of activitiesPublicGenerally PublicPublicPublic or non-Public
Patent Licensing Commitment for this Group's DeliverablesDefined in Section 3 of W3C Patent PolicyNoDefined in section 3 of W3C Community Contributor License Agreement (CLA) or Final Specification AgreementDefined in section 3 of W3C Community Contributor License Agreement (CLA) or Final Specification Agreement
Patent Disclosure ObligationDefined in Section 6 of W3C Patent PolicyDefined in Section 6 of W3C Patent PolicyDefined in Section 6 of W3C Patent Policy; no new obligations under CLA/FSADefined in Section 6 of W3C Patent Policy; no new obligations under CLA/FSA
Copyright for documentsSpecified in charterSpecified in charterW3C Community Contributor License Agreement (CLA), Final Specification AgreementW3C Community Contributor License Agreement (CLA), Final Specification Agreement or W3C Document License
Copyright for softwareW3C Software License generallyW3C Software License generallyGroup determines, but expectation is compatibility with Open Source Software Licenses.Group determines, but expectation is compatibility with Open Source Software Licenses.
Chair selectionAppointed by TeamAppointed by TeamGroup determinesGroup determines
Access to Member siteFor IEs depends on charterFor IEs Depends on charterNoNo
Decision-making based on consensusRequiredRequired where applicableRecommended where applicableRecommended where applicable
Expectations regarding scope overlap with other groupsActively avoidedActively avoidedAcceptable but not recommendedAcceptable but not recommended
135 | Note: A previous version of this table included Incubator Groups, but W3C closed the Incubator Activity in 2012. 136 | 137 |
138 | -------------------------------------------------------------------------------- /proposals/cg-lifecycle.md: -------------------------------------------------------------------------------- 1 | # Community Group Lifecycle 2 | 3 | Status: This is a proposal for discussion; it does not yet represent consensus. 4 | 5 | ## Background 6 | 7 | Today we close Community Groups for several reasons: 8 | 9 | * They complete their work successfully 10 | * They become inactive 11 | * They are creating confusion or perceived harm 12 | 13 | When we [close a group](https://www.w3.org/community/council/wiki/Closing_a_Community_or_Business_Group), we: 14 | 15 | * Update the description to indicate that the group has closed and (where known) indicate where the activity continues 16 | * Deactivate the mailing lists (except where another group takes up those lists) and other tools (e.g., repos) 17 | * Empty the list of participants 18 | 19 | We have, on rare occasions, re-opened Community Groups when that community believes the time is right to continue their work. Although it is easy to re-open a CG in our systems, there is a cost for people to rejoin the group, primarily from needing to secure permission from legal departments to sign the CLA. 20 | 21 | Our [practice](https://www.w3.org/community/council/wiki/Closing_a_Community_or_Business_Group) has long been to reach out to inactive CGs every six months to understand their situations. In some cases, groups say things like "We're not active now, but we expect to be in six months." or "We are awaiting a grant in order to continue the work." or "The situation is unclear right now, can we stay open a little longer?" or "Our specification is stable and we have one implementation. It may be a while before we get a second implementation." 22 | 23 | ## Goals 24 | 25 | Below we propose a new CG status of "dormant" designed to: 26 | 27 | * Communicate more clearly the a CG's expectation that **work has slowed, but not stopped** (and set some expectations about timing for when the group expects to become active again). 28 | * Give us an easier way to reach a community, even if that community is not currently developing deliverables. This can be useful, for example, in situations where there might be a desire to transfer a Specification to an SDO. 29 | 30 | In addition, because we do reopen CGs, and because some people have indicated that "closed" sounds overly negative, we propose to change the "Closed" state to "Archived" (a label borrowed from GitHub). 31 | 32 | ## Design Principles 33 | 34 | * **Enforcement is not a goal** (e.g., by freezing group participation or tooling). The Dormant state communicates an expectation. 35 | * **Staff outreach will be reduced** but monitoring will continue. If the Staff detects inconsistencies with the dormant expectation we will work with the group to resolve them. 36 | 37 | ## Policy 38 | 39 | ### Entering dormant state 40 | 41 | * Any request to make a group dormant must be acknowledged by all the chairs. 42 | * The request must include information that will be shared publicly: 43 | * Rationale for why the group is becoming dormant. 44 | * An estimate (even rough) of how much time the group expects to be dormant. 45 | * The Community Development Lead the decides whether to make the group dormant. If so, the staff implements making the group dormant (see below). 46 | 47 | ### During dormant state 48 | 49 | * While the group is dormant, people may still join or leave the group, and the chairs may change. 50 | * W3C will not invite the group to TPAC or other events. (The group should reopen if planning that level of activity.) 51 | * W3C staff will continue to monitor group activity but only expects to reach out to the group if regular activity is detected. 52 | 53 | ### Returning to active state 54 | 55 | * A dormant group must have chairs to be reactivated. 56 | * Any request to reactivate a group must be acknowledged by all the chairs. 57 | * The request to reactivate the group must include information that will be shared publicly: 58 | * Context for why the group is being reactivated 59 | * The Community Development Lead the decides whether to reactivate the group and implements accordingly. 60 | 61 | ### Closing a dormant group 62 | 63 | * The staff may close the group at any time, but should only do so after sending email to the group's list and allowing time for participants to respond. Some reasons staff might close a group: 64 | * The chairs request that the group be closed. 65 | * There are no longer any chairs and nobody volunteers to become chair. 66 | * The group's work has been transferred to another group. 67 | * The staff perceives that there is no longer interest in the work. 68 | * The staff perceives harm or confusion with the group in its dormant state. 69 | 70 | ## Considerations 71 | 72 | ### Specifications 73 | 74 | * The fact that a CG is dormant (and why) is an important piece of information to communicate around any Specification being developed by the CG. To avoid confusion, it would help to communicate clearly in every Specification developed by the CG what the community should expect (e.g, the specification is not likely to change while the group is dormant). This might be achieved by simple status section update. 75 | 76 | ## Implementation 77 | 78 | * Update tools to use "Archived" instead of "Closed" 79 | * Add "Dormant" state to state machine. It is possible to go from "Dormant" back to "Created" and also from "Dormant" to "Archived" 80 | * It should not be possible (and is not useful) to go from "Archived" to "Dormant." 81 | * Update relevant documentation 82 | 83 | ### CG site 84 | 85 | * Put dormant groups lower in the sorted list (by activity) 86 | * When someone clicks on the “Join” button, the join page should tell them that the group is dormant (with a link to the definition of dormant in the revised CG process.) 87 | * In home pages for the CG (whether it’s the WordPress instance or the /groups/cg page) there should be a cautionary statement: "Note: this group is currently dormant” which a link to the definition of dormant. 88 | 89 | ### Differences when entering closed or dormant states 90 | 91 | | Implementation | Archived | Dormant | 92 | | ------------- | ------------- | ------------- | 93 | | Update group description | Yes (with any links to other venues) | Yes (with rationale and estimated duration) | 94 | | Deactivate mailing lists| Yes generally | No generally | 95 | | Disassociated lists from group | Only those remaining open | No | 96 | | Update the mailing lists archive headers | Yes | No | 97 | | Update GitHub repo(s) | Deactivate, with updated language | Set expectations about dormant state | 98 | | Empty participant list | Yes | No | 99 | | Change group status in database | Yes (archived) | Yes (dormant) | 100 | 101 | -------------------------------------------------------------------------------- /proposals/continued-participation.md: -------------------------------------------------------------------------------- 1 | # Support for continued participation in a Working Group by CG contributors 2 | 3 | **Status**: This is a **draft** policy for discussion. The staff is planning an [experiment with this policy](#experiment). 4 | 5 | According to CG participants, a major hurdle (if not the most important hurdle) for advancing to standardization is the expectation that non-Members will need to become W3C Members. As part of lowering barriers for specifications with traction to advance to standardization, we propose that eligible contributors to a CG specification be invited to continue to participate in the W3C Working Group that takes up that specification, without requiring W3C Membership. In this document we enumerate some considerations, options, and our preferred approach. 6 | 7 | ## Policy 8 | 9 | ### Definition of substantive contribution 10 | 11 | In this document, a "substantive contribution" to a CG specification is one that meets the requirements of class 3 or 4 in [section 6.2.3 Classes of Changes](https://www.w3.org/policies/process/#substantive-change) in the Process Document. 12 | 13 | ### Eligibility 14 | 15 | To be eligible for continued participation in a Working Group under this policy, a CG participant: 16 | 17 | * must not be an employee of a W3C Member organization, 18 | * must have made at least one substantive contribution to a CG specification, and 19 | * must be able to identify the substantive contribution(s). 20 | 21 | If there are doubts about whether contributions were substantive, the staff will determine eligibility (typically after discussion with the CG Editors and Chairs). 22 | 23 | An individual who has contributed to multiple specifications may participate in multiple Working Groups under this policy. 24 | 25 | This policy applies to individual contributors, not to their employers. However, more than one individual from a non-Member organization may be individually eligible under this policy. 26 | 27 | ### Invitation to participate 28 | 29 | Eligible individuals are invited by the staff to participate in a Working Group that has taken up the relevant specification. Eligible individuals may seek invitations from the staff. 30 | 31 | Invitations are reviewed whenever the Working Group is rechartered or when the individual's employment affiliations change. 32 | 33 | The staff may revoke an invitation at any time, although this is expected to be rare. The lack of contributions within the Working Group should generally **not** result in revocation of an invitation. 34 | 35 | No Working Group Chair approval of an invitation is required under this policy. 36 | 37 | ### Scope of participation: all Working Group specifications 38 | 39 | Some Working Groups (e.g., CSS) publish many Recommendation-track documents. The question arises: when an individual joins a Working Group under this policy, is the scope of their participation limited to the specification they worked on in the CG, or does it extend to all specifications developed by the Working Group? 40 | An individual invited to a Working Group under this policy is considered a full participant, and may participate in discussions beyond the CG specification to which they contributed. 41 | 42 | ### Intellectual property: organizational patent commitment 43 | 44 | An IPR commitment from the individual's employer (rather than an "individual commitment") increases the confidence of the Web community in the IPR safety of the specification transferred to the Working Group. 45 | 46 | In order for an individual to participate in a Working Group under this policy, their primary employer (or other relevant entity) must make an organizational commitment to the W3C Patent Policy for the Working Group. 47 | 48 | ### Fees: zero cost 49 | 50 | Through this policy, W3C acknowledges that the Web community has benefited from voluntary contributions to Community Group specifications. 51 | 52 | An individual invited to a Working Group under this policy is therefore not required to pay a fee. The individual's primary employer (or other relevant entity) is not required to become a W3C Member (but, of course, is welcome to join as a paying Member). 53 | 54 | ## Experiment 55 | 56 | We propose to conduct an experiment to test the following hypothesis: 57 | 58 | > A zero-fee continued participation policy will provide sufficient motivation that some Community Groups will decide to pursue standardization despite previous reluctance to do so because of Membership fees. 59 | 60 | ### Structure of the experiment 61 | 62 | 1. Work with at least two Community Groups that have Specifications with traction. 63 | 2. Establish clearly that: 64 | * They want their Specification(s) to advance to a W3C Working Group (existing or new) 65 | * They are reluctant to take this step because significant contributors are concerned about Member fees. 66 | 3. Make clear to these CGs that significant contributors (as defined above) can participate as Invited Experts, as long as their organization makes an organizational patent commitment. 67 | 4. Track 68 | * Whether these groups decide to move to standardization in a W3C Working Group. 69 | * If the Specification(s) are taken up in a Working Group, how many non-Members from the CGs actually join the Working Group, including having their organization sign the IPR commitment. 70 | * If eligible contributors choose not to join a Working Group, we will also interview them to understand why not (e.g., the requirement for an organizational IPR commitment). 71 | 72 | ### IPR commitments 73 | 74 | We will rely on the existing [Invited Expert agreement](https://www.w3.org/invited-experts/agreement-2023/) and simply ask organizations to make organizational patent commitments (e.g., via email acknowledgment). 75 | 76 | > Note: Parties who want to make an IPR commitment over a W3C Working Group specification without joining the Working Group may do so, but the details are outside the scope of this policy. 77 | 78 | ## Future implementation considerations 79 | 80 | This policy resembles the [Invited Expert policy](https://www.w3.org/policies/process/#invited-expert-wg) with several modifications: 81 | 82 | * An organizational patent commitment is required rather than an individual commitment. 83 | * No approval by Working Group Chairs is required. 84 | 85 | In the case of a successful [experiment](#experiment) there are two ways to modify existing W3C policies to accommodate this new policy: 86 | 87 | * Modify the Process Document to support a new [type of participant](https://www.w3.org/policies/process/#chartered-group-participants) and create an Agreement for those participants to sign, or 88 | * Modify the [Invited Expert agreement](https://www.w3.org/invited-experts/agreement-2023/) to support this policy. 89 | 90 | We expect to gather feedback on these options. 91 | -------------------------------------------------------------------------------- /proposals/spec-lifecycle.md: -------------------------------------------------------------------------------- 1 | # CG Specification Lifecycle 2 | Status: This is a proposal for discussion; it does not yet represent consensus. 3 | 4 | This topic was discussed in a breakout session during the AC 2025 meeting; see the [slides](https://www.w3.org/2025/Talks/cg-breakout-ac2025.pdf). 5 | 6 | # Motivation 7 | 8 | The full life cycle of _W3C Working Group specifications_ has grown more complex over time as a tool to communicate important information to readers of a specification such as: 9 | 10 | * The measure of consensus associated with a specification. 11 | * Whether a specification should be implemented experimentally or has been successfully implemented by independent parties. 12 | * Whether wide review is actively being sought. 13 | * W3C endorsement signals: 14 | * W3C as an organization endorses the work. 15 | * W3C has rescinded such endorsement. 16 | * The work has been abandoned prior to endorsement. 17 | 18 | For _Community Group specifications_, we have historically only identified two stages: 19 | 20 | * Draft 21 | * Final. The “Final” stage has served two purposes: 22 | * Set expectations that the specification is stable. 23 | * Secure stronger IPR commitments, for example, as a precursor to transferring the specification to a Working Group for standardization. 24 | 25 | However, we observe that more stages could be useful to communicate certain realities: 26 | 27 | * Another organization has taken up the work (e.g., for standardization) and so the Community Group is no longer the “owner.” 28 | * A Community Group has stopped work either following an explicit decision or because they abandoned their work. 29 | 30 | In addition, as part of a plan to enhance the Community Group program, we plan to improve communication about the status of Community Group specifications and how to use or refer to them. 31 | 32 | # Audiences 33 | 34 | We seek to communicate specification status to these audiences: 35 | 36 | * CG Participants 37 | * Implementers (of APIs, for example in a browser) 38 | * Adopters (e.g., developers of Web applications) 39 | * Horizontal review groups at W3C 40 | * SDOs (especially those who may standardize CG Specifications) 41 | * Regulators 42 | 43 | # Communication of specification status 44 | 45 | ## Maturity stages 46 | 47 | * **Draft** 48 | * Meaning: In development in this Community Group. 49 | * **Abandoned** 50 | * Meaning: The CG has stopped work on the document, either by explicitly abandoning the work, or simply no longer working on it. The status section of the document explains the context for the abandonment. 51 | * **Transferred** 52 | * Meaning: Transferred for more development; no longer in development in this CG. May be in development or standardization elsewhere. The status section of the document should explains the context for the transfer. 53 | 54 | ### Living documents v snapshots 55 | 56 | Groups generally publish living documents, meaning they make changes in place (at the same URL). 57 | 58 | There are situations (e.g., related to IPR) where it is useful or necessary to create snapshots of a document with the expectation 59 | that no substantive changes will be made over time at that URL. 60 | 61 | It will be useful to communicate to readers when they are looking at a snapshot versus a living document. 62 | 63 | **Note**: For groups with different levels or versions of specifications, it will also be useful to communicate 64 | to readers when a new level or version is available. 65 | 66 | ## Status signals 67 | 68 | ### Version management 69 | 70 | Status signals are likely to come from both curated sources and metadata already managed in other venues. 71 | 72 | ### Development status 73 | 74 | * **Group status**. Typically managed through W3C database (e.g., group open, closed, or dormant) 75 | * **Community support**. Is there strong support for the specification? Strong opposition? Alternative proposals? 76 | * **Specification stability**. Indicate community expectation for specification stability. Would significant changes disrupt the ecosystem of the Specification (e.g., in terms of adoption or references)? One specific use case is to send a "last call" stability signal. Could include "last modified" date here or in details section. 77 | * **Implementer participation**. Are potential implementers of the specification participating in its development? 78 | 79 | ### Implementer guidance 80 | 81 | The group encourages experimental implementation and feedback (or "not yet"). 82 | 83 | * **Test suite**. URL to tests or 'None' 84 | * **Implementation traction**. Determined from announcements of intent to prototype, implement, ship; automated detection of shipping features. 85 | 86 | ### Adopter guidance 87 | This technology is experimental and **will** change. 88 | 89 | * **Experimentation status**. Whether it is a good time to experiment with the technology (or not). 90 | * **Known adopter interest**. Identify known pilots or experiments, examples of real-world deployments or expressions of interests to use the relevant feature. 91 | * **Patent licensing commitments**. Typically determined by CLA, but will differ if spec was part of a call for final specification commitments. 92 | 93 | ### Standardization plan 94 | 95 | This is **not** a W3C standard. Standardization plans: 96 | 97 | * **Plans**. We are developing separately ideas for metadata to describe standardization plans (e.g., if plan to standardize, what venue and on what schedule); whether that data lives in a separate document or is part of other status signals data remains to be seen. 98 | * **Revision management**. Does the CG work on new versions only? Does it provide input to a standards group on an ongoing basis? Note: This information is only necessary for the stage "transferred". 99 | 100 | ## Detailed information 101 | 102 | This information might appear after the "top line" status signals (e.g., in expandable UX). 103 | 104 | ### Implementations 105 | 106 | We foresee a list of implementation blocks. For each block: 107 | 108 | * **Name** 109 | * **Class of implementation** 110 | * Example: browser 111 | * Example: server 112 | * Example: plug-in or polyfill 113 | * **Status of implementation** 114 | * Intent to implement 115 | * Prototype 116 | * Shipping 117 | 118 | ### Ideas for data management 119 | 120 | * Status information is specified in a file in the specification repo. It should be easy to determine the last modified date of that file. 121 | * The status information is surfaced in the specification (at least). 122 | * Integrate into respec and bikeshed 123 | * for snapshots, the status is the one set at time of publication 124 | * for live documents, by default it is the one set of a time of publication, but we expect there will be a (JavaScript) mechanism that allows to mark documents as abandoned/transferred via data under W3C's control, to be used when the live doc does not reflect the real status of the spec and can't be otherwise updated (e.g. no one active with write access to the repo) 125 | * Editors are responsible for maintaining the data. 126 | * Nice to have: notification of status changes. 127 | * Tools can monitor status information and report findings, such as: 128 | * The file says there's one implementation, but we detect more than one. 129 | * The file set an expectation about a time frame for advancement to another SDO and that time has elapsed. 130 | 131 | ## Usage Guidance 132 | 133 | * Reports (and repos) should include usage guidance that depend on the maturity level and status signals. It might be interesting to see if we can generate the usage guidance systematically for each combination of maturity level and status signals. 134 | * Standardization expectation = “intent => This specification appears to be gaining traction and the CG has indicated an intent to advance to standardization. We recommend checking periodically to see whether the specification has been transferred to a group for standardization.” 135 | 136 | -------------------------------------------------------------------------------- /policies/summary.html: -------------------------------------------------------------------------------- 1 | Patent and Copyright Policy SummaryThis is a summary of the W3C Community Contributor License Agreement (CLA) and W3C Community Final Specification Agreement. The sole purpose of this document is to provide a helpful summary of the policies. It has no legal standing. For authoritative information, please refer to the policies themselves. 2 |

Goals of the Policies

3 | W3C Community and Business Groups provide people with a place to do pre-standards work at W3C. When people collaborate on a Specification, they contribute intellectual property (IP). It is a high-level goal of these policies to ensure that Specifications produced under these policies can be implemented on a Royalty-Free (RF) basis. These policies also seek to facilitate participation by those organizations or people who have IP. Thus, considerations include: 4 | 12 |

General Overview

13 | The two agreements include provisions for both copyright and patent rights; see below for details. The agreements are from participants and to implementers (or other licensees). W3C does not own any patents or copyrights as a result of these agreements. 14 | 15 | Together, the agreements form a two-step policy so that people make lightweight commitments when work starts and more comprehensive commitments once work is mature. 16 |
    17 |
  1. Initially, a participant makes certain commitments regarding their own Contribution under the W3C Community Contributor License Agreement (CLA).
  2. 18 |
  3. Later, a participant can make a voluntary commitment regarding the entire specification under the W3C Community Final Specification Agreement (FSA).
  4. 19 |
20 | Please note that signing the CLA is a requirement for joining a group, but signing the FSA is voluntary. 21 | 22 | The two-step policy is thus designed to make it easier for organizations to start work quickly, to limit their licensing obligations during development, and to voluntarily make a more complete commitment to the community at a later time. This gives implementers some "patent protection" during the draft phase, and the possibility of greater protection once the specification is stable. 23 | 24 | 28 |

Patent Licensing Summary

29 | Those who sign the agreements make Royalty-Free licensing commitments to implementers of the specification to which the material was contributed. The policies are not actual patent licenses but instead (like the W3C Patent Policy) define requirements of any license granted under the policy. 30 | 31 | To give IPR holders confidence that their licensing obligations extend only to material that they intend to commit, the policy includes several provisions to scope the commitment. The primary scoping provisions of the CLA are: 32 | 44 | The FSA is structured similarly, but because it refers to a specific, unchanging document, it does not include provisions related to opt-out, modifications, and so on. 45 | 46 | Note that there are no new patent disclosure obligations under the CLA or FSA. 47 |

Transition to W3C Standards Track

48 | The CLA and FSA were designed in several ways to make it easy for work to transition to the W3C standards track. 49 | 53 |

Additional Resources

54 | -------------------------------------------------------------------------------- /transfer-considerations.md: -------------------------------------------------------------------------------- 1 | # Considerations when transferring a CG Specification for Standardization 2 | 3 | Status: This is a draft with no standing. Questions? Raise issues in this repo or contact Ian Jacobs and Dominique Hazaël-Massieux. 4 | See also the AB [Priority Project on Incubation](https://www.w3.org/wiki/AB/2024_Priorities#Incubation) & 5 | [white paper on incubation (Member-only)](https://github.com/w3c/AB-memberonly/blob/main/documents/Incubation.md), [Recommendation Track Readiness Best Practices](https://www.w3.org/guide/standards-track/), and the existing [CG transition guide](https://www.w3.org/guide/process/cg-transition.html). 6 | 7 | ## Introduction 8 | 9 | It is a goal of the Community Group program that specifications with traction advance to a standardization process, either within W3C or another SDO. The W3C staff seeks to support Community Groups as soon as they begin to contemplate standardization. We document here common questions and considerations when transferring a CG Specification for standardization. 10 | 11 | ## Readiness Considerations 12 | 13 | ### Community 14 | 15 | * Has the community documented the use cases the CG Specification seeks to address (e.g., is there an explainer)? 16 | * Have the parties who have those use cases been involved in the development of the Specification? 17 | * Have implementers been involved in its development? Given signals of interest (e.g., actual implementations or announcements of intent to prototype)? 18 | * Are there multiple independent parties contributing to the CG Specification, or is the effort largely driven by a single organization or individual? 19 | * Is there consensus within the group for the approach? 20 | * Are there strong signals of disagreement within or outside the group? Have there been attempts to work through those? 21 | * Do you have a regular point of contact on the W3C staff? 22 | 23 | ### Specification context 24 | 25 | * Is the CG Specification actively changing, or stable (and if so, when was it last modified)? 26 | * How many independent implementations are there? 27 | * Does the Specification depend heavily on other technologies that are not yet on a standards track? 28 | 29 | ### Standardization opportunity 30 | 31 | * Are there aspects of the opportunity that are time-sensitive? 32 | * What are the signals of industry demand for a standard in this space? 33 | * Are there pilots? 34 | * What are the signals of a regulatory demand for a standard in this space? 35 | * Are there references to the CG Specification from other specifications (from CGs, W3C WGs, or other SDOs)? 36 | * Are there other signals that lead the group to believe that there is an emerging standardization opportunity? 37 | 38 | ### Intellectual property 39 | 40 | * Does the group plan to call for [Final Specification](https://www.w3.org/community/about/process/final/) commitments (which may be useful but is not required before a transfer)?" 41 | * Are there any known IPR issues related to the CG Specification? 42 | * Are you using the IPR checker on your repos? 43 | 44 | ## Handoff Considerations 45 | 46 | ### Venue 47 | 48 | #### General Considerations 49 | 50 | * What is the nature of the topic among these options: 51 | * Core Web technology that can be leveraged in a wide variety of use cases. 52 | * Vertical technology (e.g., health care and life sciences, real estate). If so, what is the argument for standardization at W3C? For example, given the linked data community at W3C, there may be an argument for standardization of a broadly useful linked data specification. 53 | * Horizontal (e.g., sustainability, accessibility, internationalization) that affects work across the consortium? How does this work support the W3C mission? 54 | * If CG participants are considering multiple venues, what are the pros and cons of each option? 55 | * What do you perceive as obstacles to success at any of these venues? 56 | * Would dividing up the standardization effort among multiple organizations make sense? 57 | 58 | #### W3C Considerations 59 | 60 | * What is the overlap between Community Group participants and the W3C Membership? In cases where there is little overlap, it can be more challenging to build support among the Membership for the creation of a new Working Group. The W3C staff can help in several ways: 61 | * Working with the CG to understand which W3C Members may become champions for the work. 62 | * Organizing discussions with organizations interested in joining W3C for this work. 63 | * What is the relationship between the CG Specification and other work streams at W3C? 64 | * Is there an existing Working Group that would make a reasonable home for the CG Specification? 65 | * Are there other Community Groups working on similar projects? Does it make sense for several CGs to work together as a way to gain more support from the broader Membership? 66 | * Whare are the perceived barriers to starting a W3C Working Group? 67 | * **Enhancement in development**: Traditionally within W3C, Working Group participation has been reserved for W3C Members and Invited Experts. We seek to change this practice so that non-Member CG participants who have made significant contributions to a CG Specification are invited to participate at no cost in the Working Group that takes up the CG Specification, provided that the individual’s employer makes an organizational-level commitment to the W3C Working Group for that same Specification. 68 | 69 | CG Chairs are also encouraged to familiarize themselves with the [W3C Process for creating a Working Group](https://www.w3.org/policies/process/#group-lifecycle) and the [operational details](https://www.w3.org/guide/process/charter.html#new-charters) of chartering a Working Group. 70 | 71 | #### Other SDO Considerations 72 | 73 | * What are the confidentiality policies of the SDO? This may have an impact on revision management strategies. 74 | * Does W3C have a [liaison](https://www.w3.org/liaisons/) with any of the other SDOs? 75 | 76 | ### Intellectual Property Transfer 77 | 78 | * See [Are IPR commitments in place?](https://www.w3.org/guide/process/cg-transition.html#are-ipr-commitments-in-place) when requesting publication on the Rec Track. 79 | 80 | It is important that participants be aware of how IPR flows when the Specification is transferred to a W3C Working Group or another SDO. 81 | 82 | #### W3C Considerations 83 | 84 | CG participants agree to the terms of the [Contributor Licensing Agreement (CLA)](https://www.w3.org/community/about/process/cla/) for Specifications developed by the CG. Contributors to a Specification agree to license (“perpetual, worldwide, non-exclusive, no-charge, royalty-free”) their Contributions to parties who make use of those Contributions as part of implementing the Specification. 85 | 86 | Under the CLA, Contributors also agree that if the CG Specification is taken up by a W3C Working Group, the Contributions remain available under similar licensing for parties who make use of an eventual W3C Recommendation that includes the Contributions. In other words, if standardization happens within W3C, parties do not need to ask for any new commitments from Contributors to the CG Specifications; their commitments carry forward (by default) to a future Working Group. 87 | 88 | #### Other SDO Considerations 89 | 90 | The CLA does not include similar provisions for transfers to other standards bodies. This means that standards bodies that wish to take up a CG Specification for standardization need to secure new copyright and patent licenses from (at least significant) Contributors. 91 | 92 | This means that the other SDO may need to identify the significant contributors to the CG Specification. The W3C staff can help identify significant Contributors to a CG Specification (through [tooling](https://www.w3.org/guide/process/cg-transition.html#github-repository-management)), but typically the editor(s) of a CG Specification and Chairs have a good sense of who contributes text to a Specification. 93 | 94 | It is also useful to consider the following IPR topics: 95 | 96 | * Because the CG participants have already granted a non-exclusive license for the CG Specification, they cannot issue an exclusive license to other parties. W3C can, in the future, still take up the work in a Working Group (although it might not choose to do so for social / liaison reasons). 97 | * Will Contributors be asked to transfer ownership of their Contributions to another entity? In that case, what rights will Contributors retain about their Contributions? This may have an impact on [revision management](#revision-management) strategies. 98 | * Does the other SDO have robust IPR and other legal policies in place to support further development of the specifications? 99 | * What is the policy of the other SDO in terms of reuse of material in a Community Group (for example, if the CG were to work on a subsequent revision of a Specification and would want to incorporate revisions made by the SDO)? 100 | * Is there a memorandum of understanding or other agreement between W3C and the other SDO on transfer of W3C-incubated specifications? If so, will the transfer follow the terms of such agreement? 101 | * ISO-specific Consideration: [W3C is a PAS Submitter to ISO](https://www.w3.org/2010/04/pasfaq), but only for Recommendations. That is: one way to transfer a CG Specification to ISO is to launch a W3C Working Group to develop a Recommendation, then use the PAS process to submit it to ISO. 102 | 103 | ### Revision management 104 | 105 | * Are the Community Group participants prepared to hand change control for the CG Specification over to a standards group? 106 | * What is the Community Group’s expectation about continuing to work on the topic after handing off the CG Specification for standardization? 107 | * For example, a Community Group might a venue for developers to provide feedback and express concerns, while a Working Group might focus on standardization of the specification. 108 | * Do the Community Group and the potential venue for standardization share expectations about how revisions will be handled? 109 | * From a W3C perspective, it is acceptable for a "twinned" Community Group to continue to incubate new material relative to a Specification that it has handed off to a standards group (a W3C Working Group or other SDO). 110 | * In this case, clear communication about “what is being standardized” and “what is being incubated” is critical to avoid market confusion. 111 | -------------------------------------------------------------------------------- /policies/final.html: -------------------------------------------------------------------------------- 1 | W3C Community Final Specification AgreementTo secure commitments from participants for the full text of a Community or Business Group Report, the group may call for voluntary commitments to the following terms; a summary is available. See also the related W3C Community Contributor License Agreement. 2 |
3 |
    4 |
  1. 1. The Purpose of this Agreement. 5 | This Agreement sets forth the terms under which I make certain copyright and patent rights available to you for your implementation of the Specification. Any other capitalized terms not specifically defined herein have the same meaning as those terms have in the W3C Patent Policy, and if not defined there, in the W3C Process Document.
  2. 6 |
  3. 2. Copyrights. 7 |
      8 |
    1. 2.1. Copyright Grant. I grant to you a perpetual (for the duration of the applicable copyright), worldwide, non-exclusive, no-charge, royalty-free, copyright license, without any obligation for accounting to me, to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, distribute, and implement the Specification to the full extent of my copyright interest in the Specification.
    2. 9 |
    3. 2.2. Attribution. As a condition of the copyright grant, you must include an attribution to the Specification in any derivative work you make based on the Specification. That attribution must include, at minimum, the Specification name and version number.
    4. 10 |
    11 |
  4. 12 |
  5. 3. Patents. 13 |
      14 |
    1. 3.1. Patent Licensing Commitment. I agree to license my Essential Claims under the W3C Community RF Licensing Requirements. This requirement includes Essential Claims that I own and any that I have the right to license without obligation of payment or other consideration to an unrelated third party. W3C Community RF Licensing Requirements obligations made concerning the Specification and described in this policy are binding on me for the life of the patents in question and encumber the patents containing Essential Claims, regardless of changes in participation status or W3C Membership. I also agree to license my Essential Claims under the W3C Community RF Licensing Requirements in derivative works of the Specification so long as all normative portions of the Specification are maintained and that this licensing commitment does not extend to any portion of the derivative work that was not included in the Specification.
    2. 15 |
    3. 3.2. Optional, Additional Patent Grant. In addition to the provisions of Section 3.1, I may also, at my option, make certain intellectual property rights infringed by implementations of the Specification, including Essential Claims, available by providing those terms via the W3C Web site.
    4. 16 |
    17 |
  6. 18 |
  7. 4. No Other Rights. Except as specifically set forth in this Agreement, no other express or implied patent, trademark, copyright, or other property rights are granted under this Agreement, including by implication, waiver, or estoppel.
  8. 19 |
  9. 5. Antitrust Compliance. I acknowledge that I may compete with other participants, that I am under no obligation to implement the Specification, that each participant is free to develop competing technologies and standards, and that each party is free to license its patent rights to third parties, including for the purpose of enabling competing technologies and standards.
  10. 20 |
  11. 6. Non-Circumvention. I agree that I will not intentionally take or willfully assist any third party to take any action for the purpose of circumventing my obligations under this Agreement.
  12. 21 |
  13. 7. Transition to W3C Recommendation Track. The Specification developed by the Project may transition to the W3C Recommendation Track. The W3C Team is responsible for notifying me that a Corresponding Working Group has been chartered. I have no obligation to join the Corresponding Working Group. If the Specification developed by the Project transitions to the W3C Recommendation Track, the following terms apply: 22 |
      23 |
    1. 7.1. If I join the Corresponding Working Group. If I join the Corresponding Working Group, I will be subject to all W3C rules, obligations, licensing commitments, and policies that govern that Corresponding Working Group.
    2. 24 |
    3. 7.2. If I Do Not Join the Corresponding Working Group. 25 |
        26 |
      1. 7.2.1. Licensing Obligations to Resulting Specification. If I do not join the Corresponding Working Group, I agree to offer patent licenses according to the W3C Royalty-Free licensing requirements described in Section 5 of the W3C Patent Policy for the portions of the Specification included in the resulting Recommendation. This licensing commitment does not extend to any portion of an implementation of the Recommendation that was not included in the Specification. This licensing commitment may not be revoked but may be modified through the exclusion process defined in Section 4 of the W3C Patent Policy. I am not required to join the Corresponding Working Group to exclude patents from the W3C Royalty-Free licensing commitment, but must otherwise follow the normal exclusion procedures defined by the W3C Patent Policy. The W3C Team will notify me of any Call for Exclusion in the Corresponding Working Group as set forth in Section 4.5 of the W3C Patent Policy.
      2. 27 |
      3. 7.2.2. No Disclosure Obligation. If I do not join the Corresponding Working Group, I have no patent disclosure obligations outside of those set forth in Section 6 of the W3C Patent Policy.
      4. 28 |
      29 |
    4. 30 |
    31 |
  14. 32 |
  15. 8. Conflict of Interest. I will disclose significant relationships when those relationships might reasonably be perceived as creating a conflict of interest with my role. I will notify W3C of any change in my affiliation using W3C-provided mechanisms.
  16. 33 |
  17. 9. Representations, Warranties and Disclaimers. I represent and warrant that I am legally entitled to grant the rights and promises set forth in this Agreement. IN ALL OTHER RESPECTS THE SPECIFICATION IS PROVIDED “AS IS.” The entire risk as to implementing or otherwise using the Specification is assumed by the implementer and user. Except as stated herein, I expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the Specification. IN NO EVENT WILL ANY PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. All of my obligations under Section 3 regarding the transfer, successors in interest, or assignment of Granted Claims will be satisfied if I notify the transferee or assignee of any patent that I know contains Granted Claims of the obligations under Section 3. Nothing in this Agreement requires me to undertake a patent search.
  18. 34 |
  19. 10. Definitions. 35 |
      36 |
    1. 10.1. Agreement. “Agreement” means this W3C Community Final Specification Agreement.
    2. 37 |
    3. 10.2. Corresponding Working Group. “Corresponding Working Group” is a W3C Working Group that is chartered to develop a Recommendation, as defined in the W3C Process Document, that takes the Specification as an input.
    4. 38 |
    5. 10.3. Essential Claims. “Essential Claims” shall mean all claims in any patent or patent application in any jurisdiction in the world that would necessarily be infringed by implementation of the Specification. A claim is necessarily infringed hereunder only when it is not possible to avoid infringing it because there is no non-infringing alternative for implementing the normative portions of the Specification. Existence of a non-infringing alternative shall be judged based on the state of the art at the time of the publication of the Specification. The following are expressly excluded from and shall not be deemed to constitute Essential Claims: 39 |
        40 |
      1. 10.3.1. any claims other than as set forth above even if contained in the same patent as Essential Claims; and
      2. 41 |
      3. 10.3.2. claims which would be infringed only by: 42 |
          43 |
        • portions of an implementation that are not specified in the normative portions of the Specification, or
        • 44 |
        • enabling technologies that may be necessary to make or use any product or portion thereof that complies with the Specification and are not themselves expressly set forth in the Specification (e.g., semiconductor manufacturing technology, compiler technology, object-oriented technology, basic operating system technology, and the like); or
        • 45 |
        • the implementation of technology developed elsewhere and merely incorporated by reference in the body of the Specification.
        • 46 |
        47 |
      4. 48 |
      5. 10.3.3. design patents and design registrations.
      6. 49 |
      50 | For purposes of this definition, the normative portions of the Specification shall be deemed to include only architectural and interoperability requirements. Optional features in the RFC 2119 sense are considered normative unless they are specifically identified as informative. Implementation examples or any other material that merely illustrate the requirements of the Specification are informative, rather than normative.
    6. 51 |
    7. 10.4. I, Me, or My. “I,” “me,” or “my” refers to the signatory.
    8. 52 |
    9. 10.5 Project. “Project” means the W3C Community Group or Business Group for which I executed this Agreement.
    10. 53 |
    11. 10.6. Specification. “Specification” means the Specification identified by the Project as the target of this agreement in a call for Final Specification Commitments. W3C shall provide the authoritative mechanisms for the identification of this Specification.
    12. 54 |
    13. 10.7. W3C Community RF Licensing Requirements. “W3C Community RF Licensing Requirements” license shall mean a non-assignable, non-sublicensable license to make, have made, use, sell, have sold, offer to sell, import, and distribute and dispose of implementations of the Specification that: 55 |
        56 |
      1. 10.7.1. shall be available to all, worldwide, whether or not they are W3C Members;
      2. 57 |
      3. 10.7.2. shall extend to all Essential Claims owned or controlled by me;
      4. 58 |
      5. 10.7.3. may be limited to implementations of the Specification, and to what is required by the Specification;
      6. 59 |
      7. 10.7.4. may be conditioned on a grant of a reciprocal RF license (as defined in this policy) to all Essential Claims owned or controlled by the licensee. A reciprocal license may be required to be available to all, and a reciprocal license may itself be conditioned on a further reciprocal license from all.
      8. 60 |
      9. 10.7.5. may not be conditioned on payment of royalties, fees or other consideration;
      10. 61 |
      11. 10.7.6. may be suspended with respect to any licensee when licensor is sued by licensee for infringement of claims essential to implement the Specification or any W3C Recommendation;
      12. 62 |
      13. 10.7.7. may not impose any further conditions or restrictions on the use of any technology, intellectual property rights, or other restrictions on behavior of the licensee, but may include reasonable, customary terms relating to operation or maintenance of the license relationship such as the following: choice of law and dispute resolution;
      14. 63 |
      15. 10.7.8. shall not be considered accepted by an implementer who manifests an intent not to accept the terms of the W3C Community RF Licensing Requirements license as offered by the licensor.
      16. 64 |
      17. 10.7.9. The RF license conforming to the requirements in this policy shall be made available by the licensor as long as the Specification is in effect. The term of such license shall be for the life of the patents in question.
      18. 65 |
      66 | I am encouraged to provide a contact from which licensing information can be obtained and other relevant licensing information. Any such information will be made publicly available.
    14. 67 |
    15. 10.8. You or Your. “You,” “you,” or “your” means any person or entity who exercises copyright or patent rights granted under this Agreement, and any person that person or entity controls.
    16. 68 |
    69 |
  20. 70 |
71 |
72 | -------------------------------------------------------------------------------- /policies/cla.html: -------------------------------------------------------------------------------- 1 | W3C Community Contributor License Agreement (CLA)In order to participate in a Community Group or Business Group, people agree to the following terms upon joining a group; a summary is available. 2 |
3 |
    4 |
  1. 1. The Purpose and General Terms of this Contributor License Agreement (CLA). This CLA sets forth the terms under which I will participate in and contribute to the development of the Specification, if any, created by the Project. Any other capitalized terms not specifically defined herein have the same meaning as those terms have in the W3C Patent Policy, and if not defined there, in the W3C Process Document. Any source code outside the Specification created by the Project is not subject to this CLA, but rather subject to separate licensing terms for that source code. The W3C Community and Business Group Process governs the operations of the Project. The Community and Business Group Process delegates some rights to the participants of the Project to establish operational agreements. Those operational agreements must not conflict with or modify this Community and Business Group Process, the Community Contributor License Agreement (CLA), or the Final Specification Agreement. Except for the limited definitions specifically referenced herein, this CLA and the Final Specification Agreement, if I sign it, set forth my entire licensing obligations for Specifications created by the Project and supersede all prior negotiations, agreements, understandings, and obligations with respect thereto.
  2. 5 |
  3. 2. Copyrights. 6 |
      7 |
    1. 2.1. Copyright Grant. I grant to you a perpetual (for the duration of the applicable copyright), worldwide, non-exclusive, no-charge, royalty-free, copyright license, without any obligation for accounting to me, to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, distribute, and implement any Contribution to the full extent of my copyright interest in the Contribution.
    2. 8 |
    3. 2.2. Attribution. As a condition of the copyright grant, you must include an attribution to the Specification in any derivative work you make based on the Specification. That attribution must include, at minimum, the Specification name and version number.
    4. 9 |
    10 |
  4. 11 |
  5. 3. Patents. 12 |
      13 |
    1. 3.1. Patent Licensing Commitment. I agree to license my Essential Claims under the W3C CLA RF Licensing Requirements. This requirement includes Essential Claims that I own and any that I have the right to license without obligation of payment or other consideration to an unrelated third party. With the exception of the provisions of Section 5 below, W3C CLA RF Licensing Requirements obligations made concerning the Specification and described in this CLA are binding on me for the life of the patents in question and encumber the patents containing Essential Claims, regardless of changes in participation status or W3C Membership. I also agree to license my Essential Claims under the W3C CLA RF Licensing Requirements in derivative works of the Specification developed by the Project, provided that my Contribution remains intact in those derivative works. However, no additional claims are made Essential Claims in the combination of my Contribution with derivative works of the Specification.
    2. 14 |
    3. 3.2. Optional, Additional Patent Grant. In addition to the provisions of Section 3.1, I may also, at my option, make certain intellectual property rights infringed by implementations of the Specification, including Essential Claims, available by providing those terms via the W3C Web site.
    4. 15 |
    16 |
  6. 17 |
  7. 4. No Other Rights. Except as specifically set forth in this CLA, no other express or implied patent, trademark, copyright, or other property rights are granted under this CLA, including by implication, waiver, or estoppel.
  8. 18 |
  9. 5. Limited Opt-Out. I, in my sole discretion, may withdraw my Contribution, for any reason, by providing written notice of that withdrawal no later than 45 days after the date of my Contribution. Notice of withdrawal of a Contribution must be made in writing using the Project's communications mechanisms for that purpose and must describe the exact material of the particular Contribution being withdrawn. Upon providing that notice, the identified Contribution will be deemed null and void, and, not withstanding anything to the contrary herein, I will not be deemed to have incurred any obligation with respect to that Contribution. In addition, any particular Contribution will be null and void, and I will not incur any obligation as a result of it, if that Contribution is not included in the Specification within 150 days of the date of that Contribution.
  10. 19 |
  11. 6. W3C Community Contributor License Agreement Execution. I acknowledge that the goal of this CLA is to provide coverage for Contributions to the Specification, if any, created by the Project. The Final Specification itself, if any, will be subject to the W3C Community Final Specification Agreement. While I have no legal obligation to execute the W3C Community Final Specification Agreement for any version of the Specification being developed under this CLA, I agree that the selection and terms of the then current W3C Community Final Specification Agreement will not be subject to negotiation.
  12. 20 |
  13. 7. Antitrust Compliance. I acknowledge that I may compete with other participants, that I am under no obligation to implement the Specification, that each participant is free to develop competing technologies and standards, and that each party is free to license its patent rights to third parties, including for the purpose of enabling competing technologies and standards.
  14. 21 |
  15. 8. Non-Circumvention. I agree that I will not intentionally take or willfully assist any third party to take any action for the purpose of circumventing my obligations under this CLA.
  16. 22 |
  17. 9. Transition to W3C Recommendation Track. Specifications developed by the Project may transition to the W3C Recommendation Track. The W3C Team is responsible for notifying me that a Corresponding Working Group has been chartered. I have no obligation to join the Corresponding Working Group. If the Specification developed under the Project transitions to the W3C Recommendation Track, the following terms apply: 23 |
      24 |
    1. 9.1. If I join the Corresponding Working Group. If I join the Corresponding Working Group, I will be subject to all W3C rules, obligations, licensing commitments, and policies that govern that Corresponding Working Group.
    2. 25 |
    3. 9.2. If I Do Not Join the Corresponding Working Group. 26 |
        27 |
      1. 9.2.1. Licensing Obligations to Resulting Specification. If I do not join the Corresponding Working Group, I agree to offer patent licenses according to the W3C Royalty-Free licensing requirements described in Section 5 of the W3C Patent Policy for my Contributions included in the resulting Recommendation. This licensing commitment may not be revoked but may be modified through the exclusion process defined in Section 4 of the W3C Patent Policy. I am not required to join a Working Group to exclude patents from the W3C Royalty-Free licensing commitment, but must otherwise follow the normal exclusion procedures defined by the W3C Patent Policy. The W3C Team will notify me of any Call for Exclusion in the Corresponding Working Group as set forth in Section 4.5 of the W3C Patent Policy.
      2. 28 |
      3. 9.2.2. No Disclosure Obligation. If I do not join the Corresponding Working Group, I have no patent disclosure obligations outside of those set forth in Section 6 of the W3C Patent Policy.
      4. 29 |
      30 |
    4. 31 |
    32 |
  18. 33 |
  19. 10. Conflict of Interest. I will disclose significant relationships when those relationships might reasonably be perceived as creating a conflict of interest with my role. I will notify W3C of any change in my affiliation using W3C-provided mechanisms.
  20. 34 |
  21. 11. Representations, Warranties and Disclaimers. I represent and warrant that 1) I am legally entitled to grant the rights and promises set forth in this CLA and 2) I will not intentionally include any third party materials in any Contribution unless those materials are available under terms that do not conflict with this CLA and I identify any such third party materials. IN ALL OTHER RESPECTS MY CONTRIBUTIONS ARE PROVIDED “AS IS.” The entire risk as to implementing or otherwise using the Contribution or the Specification is assumed by the implementer and user. Except as stated herein, I expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the Contribution or the Specification. IN NO EVENT WILL ANY PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS CLA, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  22. 35 |
  23. 12. Definitions. 36 |
      37 |
    1. 12.1. CLA. “CLA” means this Contributor Licensing Agreement.
    2. 38 |
    3. 12.2. Contribution. “Contribution” means any original work of authorship, including any modifications or additions to an existing work, that I intentionally submit for inclusion in the Specification, and which Contribution is actually included in the Specification. For the purposes of this definition, the method by which I “submit” a Contribution means any form of electronic, oral, or written communication for the purpose of discussing and improving the Specification, but excludes any such communication that I conspicuously designate in writing as not a Contribution to one or more of the Specifications developed by the Project.
    4. 39 |
    5. 12.3. Corresponding Working Group. “Corresponding Working Group” is a W3C Working Group that is chartered to develop a Recommendation that takes the Specification as an input.
    6. 40 |
    7. 12.4. Essential Claims. “Essential Claims” shall mean all claims in any patent or patent application in any jurisdiction in the world that would necessarily be infringed by implementation of my Contributions in an implementation of the Specification. A claim is necessarily infringed hereunder only when it is not possible to avoid infringing it because there is no non-infringing alternative for implementing the normative portions of the Specification. Existence of a non-infringing alternative shall be judged based on the state of the art at the time my Contribution is included in the Specification. The following are expressly excluded from and shall not be deemed to constitute Essential Claims: 41 |
        42 |
      1. 12.4.1. any claims other than as set forth above even if contained in the same patent as Essential Claims; and
      2. 43 |
      3. 12.4.2. claims which would be infringed only by: 44 |
          45 |
        • portions of an implementation that are not specified in the normative portions of the Specification, or
        • 46 |
        • enabling technologies that may be necessary to make or use any product or portion thereof that complies with the Specification and are not themselves expressly set forth in the Specification (e.g., semiconductor manufacturing technology, compiler technology, object-oriented technology, basic operating system technology, and the like); or
        • 47 |
        • the implementation of technology developed elsewhere and merely incorporated by reference in the body of the Specification.
        • 48 |
        49 |
      4. 50 |
      5. 12.4.3. design patents and design registrations.
      6. 51 |
      52 | For purposes of this definition, the normative portions of the Specification shall be deemed to include only architectural and interoperability requirements. Optional features in the RFC 2119 sense are considered normative unless they are specifically identified as informative. Implementation examples or any other material that merely illustrate the requirements of the Specification are informative, rather than normative.
    8. 53 |
    9. 12.5. I, Me, or My. “I,” “me,” or “my” refers to the signatory.
    10. 54 |
    11. 12.6. Project. “Project” means the W3C Community Group or Business Group for which I executed this CLA.
    12. 55 |
    13. 12.7. Specification. “Specification” means any specification developed by the Project, as of the date my Contribution is first included in that specification. W3C shall provide the authoritative mechanisms for the identification of Specifications created by the Project.
    14. 56 |
    15. 12.8. W3C CLA RF Licensing Requirements. Subject to Section 5, with respect to my Contributions to the Specification, “W3C CLA RF Licensing Requirements” license shall mean a non-assignable, non-sublicensable license to make, have made, use, sell, have sold, offer to sell, import, and distribute and dispose of implementations of my Contributions in the Specification that: 57 |
        58 |
      1. 12.8.1. shall be available to all, worldwide, whether or not they are W3C Members;
      2. 59 |
      3. 12.8.2. shall extend to all Essential Claims owned or controlled by me;
      4. 60 |
      5. 12.8.3. may be limited to implementations of the Specification, and to what is required by the Specification;
      6. 61 |
      7. 12.8.4. may be conditioned on a grant of a reciprocal RF license (as defined in this policy) to all Essential Claims owned or controlled by the licensee. A reciprocal license may be required to be available to all, and a reciprocal license may itself be conditioned on a further reciprocal license from all.
      8. 62 |
      9. 12.8.5. may not be conditioned on payment of royalties, fees or other consideration;
      10. 63 |
      11. 12.8.6. may be suspended with respect to any licensee when licensor is sued by licensee for infringement of claims essential to implement the Specification or any W3C Recommendation;
      12. 64 |
      13. 12.8.7. may not impose any further conditions or restrictions on the use of any technology, intellectual property rights, or other restrictions on behavior of the licensee, but may include reasonable, customary terms relating to operation or maintenance of the license relationship such as the following: choice of law and dispute resolution;
      14. 65 |
      15. 12.8.8. shall not be considered accepted by an implementer who manifests an intent not to accept the terms of the W3C CLA RF Licensing Requirements license as offered by the licensor.
      16. 66 |
      17. 12.8.9. The RF license conforming to the requirements in this policy shall be made available by the licensor as long as the Specification is in effect. The term of such license shall be for the life of the patents in question.
      18. 67 |
      68 | I am encouraged to provide a contact from which licensing information can be obtained and other relevant licensing information. Any such information will be made publicly available.
    16. 69 |
    17. 12.9. You or Your. “You,” “you,” or “your” means any person or entity who exercises copyright or patent rights granted under this CLA, and any person or entity that person or entity controls.
    18. 70 |
    71 |
  24. 72 |
73 |
74 | -------------------------------------------------------------------------------- /policies/bg_agreement.html: -------------------------------------------------------------------------------- 1 |
2 |

International World Wide Web Consortium ("W3C")

3 | 4 |

BUSINESS GROUP PARTICIPATION AGREEMENT (the "Agreement") effective as of <{$date}> ("Effective Date"), by and between the Massachusetts Institute of Technology, having an office at 32 Vassar Street, 32-G519, Cambridge, Massachusetts 02139 ("MIT"); the European Research Consortium for Informatics and Mathematics, having an office at 2004, Route des Lucioles, BP 93, F-06902 Sophia Antipolis, France ("ERCIM"); Keio University having an office at 5322 Endo, Fujisawa, Kanagawa 252-0882, Japan ("KEIO"); Beihang University, having an office at No 37 Xueyuan Road, Haidian District, Beijing, China (collectively, "Hosts"); and <{$orgname}>, having an office at <{$orgaddr}> (the "Participant").

5 | 6 |

WHEREAS, the Participant wishes to participate in the <{$bgname}> Business Group ("Business Group") of the International World Wide Web Consortium (the "Consortium"), the purposes of which are more fully set forth in the Business Group proposal and in the then-current Community and Business Group Process, which is hereby incorporated by reference.

7 | 8 |

WHEREAS, the Hosts have agreed to the Participant's participation in the Business Group, subject to said terms and conditions; and

9 | 10 |

WHEREAS, the Participant's participation and cooperation with Members and Hosts under this Agreement will further the instruction and research objectives of Hosts in a manner consistent with their status as non-profit, tax-exempt institutions.

11 | 12 |

NOW, THEREFORE, MIT, ERCIM, KEIO, BEIHANG, AND THE PARTICIPANT AGREE AS FOLLOWS:

13 | 14 |

1. Participation and Fees.

15 | 16 |

17 | a. Business Groups include Consortium Members and non-Members ("Consortium Members" are those parties who have signed the International World Wide Web Consortium Member Agreement). The annual fee for Business Group participation, by Participants who are not Consortium Members ("Fee"), shall be as described on the Business Group Fees table. Participant agrees to pay a separate Fee, and to enter a separate Participation Agreement, for each Group, in which Participant agrees to participate.

18 | 19 |

20 | b. All Participants will be assigned for administrative purposes to a Consortium Host (the "Participant's Host"). Participants with a primary domicile in Europe, Africa and the Middle East, as defined by separate Agreements between the Hosts, shall be Participants with the ERCIM Host ("ERCIM Participants"). Participants with a primary domicile in Japan or Korea shall be Participants with the KEIO Host ("KEIO Participants"). Participants with a primary domicile in the People's Republic of China ("PRC") shall be Participants with the Beihang Host ("BEIHANG Participants"). All other Participants shall be Participants with the MIT Host ("MIT Participants"). 21 |

22 | 23 |

24 | c. The Participant hereby agrees to pay the applicable Fee. The initial Fee of <{$fee}> is due upon signature of this Agreement. For each year in which the Participant renews this Agreement according to Section 2 below, the then-current Fee listed according to Article 1.a shall be due on the anniversary of the first day of the month after W3C announced the creation of the Business Group (the "Anniversary Date"). The Business Group Participant Fee is due annually thereafter on the Anniversary Date for as long as the Business Group continues. Except as provided for in this Agreement, the Fee is non-refundable and shall be payable to the Participant's Host, in the currency stated. 25 |

26 | 27 |

d. The Participant's initial Fee shall be discounted by 50% for the initial year if Participant joins an in-progress Business Group six months or more after the Anniversary Date. 28 |

29 | 30 |

e. If Participant has subsidiaries, the rights and privileges granted under this Agreement shall extend to all subsidiaries the voting stock of which is directly or indirectly at least fifty percent (50%) owned or controlled by Participant.

31 | 32 |

f. For a Participant that is itself a consortium, user society, or otherwise has members or sponsors, the rights and privileges granted under this Agreement shall extend to any number of paid employees of the Participant who are appointed by Participant and to one other individual not employed by the Participant. Additional non-employee participants may be permitted at the discretion of the Consortium.

33 | 34 |

2. Term and Termination.

35 | 36 |

a. The Term shall start on the Effective Date as indicated above. This Agreement shall automatically renew each year on the Anniversary Date for successive one-year terms ("Renewal Terms") beginning on the Anniversary Date unless terminated as described below. 37 |

38 | 39 |

b. The Participant may terminate this Agrement by written notice to the Participant's Host no later than sixty (60) days prior to the Anniversary Date. If the Consortium receives termination notices such that the number of Organizations in the group drops below the threshold required by the Hosts for a Business Group, the Consortium may terminate the group and this Agreement by written notice to the Participant, effective as of the next Anniversary Date.

40 | 41 | 42 |

3. Intellectual Property Rights.

43 | 44 |

Contributions to and outputs from the Business Group shall be governed by the W3C Community Contributor License Agreement (CLA) and W3C Community Final Specification Agreement, both of which are hereby incorporated by reference.

45 | 46 |

Per the Process, participants may choose to license Business Group outputs under the W3C Document License. If the Group chooses the W3C Document License for its output, Participant shall assign the copyrights in its contributions to the Hosts, who shall license the resulting document to the public under the terms of the W3C Document License.

47 | 48 |

4. Use of Names.

49 | 50 |

The Participant will not use the name of MIT, ERCIM, KEIO, or BEIHANG and Hosts will not use the name of Participant in any form of publicity without written permission, which in the case of MIT shall be obtainable from the MIT Technology Licensing Office; in the case of ERCIM, from the Director of Promotion; in the case of KEIO, from the Administrative Director of The Keio Research Institute at SFC; in the case of BEIHANG, from the Institute of Science and Technology of Beihang University; and in the case of the Participant, from __________________________ .

51 | 52 | 53 |

5. Notices.

54 | 55 |

All notices or other communications to or upon either party shall be in writing delivered by first class, air mail or facsimile, dispatched to or given at the following addresses:

56 | 57 |

For MIT:

58 |
                         Susan Westhaver
 59 |                          MIT/CSAIL
 60 |                          32 Vassar Street
 61 |                          Room 32-G514
 62 |                          Cambridge, MA  02139
 63 |                          UNITED STATES
64 | 65 |

For ERCIM:

66 |
                         Philipp Hoschka
 67 |                          GEIE ERCIM Manager
 68 |                          2004, Route des Lucioles
 69 |                          Sophia Antipolis
 70 |                          F-06410 Biot
 71 |                          FRANCE
72 | 73 | 74 |

For KEIO:

75 |
                         Hitoshi Takano, Administrative Director
 76 |                          Keio Research Institute at SFC
 77 |                          Keio University/SFC
 78 |                          5322 Endo
 79 |                          Fujisawa, Kanagawa 252-0882
 80 |                          JAPAN
81 | 82 |

For BEIHANG:

83 |
                         Institute of Science and Technology of Beihang University                         
 84 |                          Room 1121, G Tower of New Main Building Beihang University
 85 |                          No 37 Xueyuan Road
 86 | 			 Haidian District
 87 | 			 Beijing
 88 | 			 CHINA
89 | 90 |

For the Participant:

91 |
 92 |                          __________________________________________
 93 |                          __________________________________________
 94 |                          __________________________________________
 95 |                          __________________________________________
 96 |                          __________________________________________
 97 |                          __________________________________________
98 | 99 |

In the event notices and statements required under this Agreement are sent by certified or registered mail by one party to the party entitled thereto at its above address, they shall be deemed to have been given or made as of the date received.

100 | 101 |

6. Relationship of Parties.

102 | 103 |

The relationship of the parties under this Agreement shall be that of a voluntary association. The Consortium is not a separate legal entity, and this Agreement does not create a partnership or joint venture. Neither MIT, ERCIM, KEIO, BEIHANG, nor the Participant can bind the other or create any relationship of principal or agent.

104 | 105 |

7. Limitation of Liability.

106 | 107 |

In the event of termination of this Agreement by MIT, ERCIM, KEIO, and BEIHANG pursuant to Section 2 hereof, the Participant shall be entitled to receive, as its sole and exclusive remedy, a refund of any portion of the Participant's duly paid and as-yet uncommitted Fee, and upon such refund, any further liability of MIT, ERCIM, KEIO, and/or BEIHANG to the Participant shall be extinguished. This remedy is in lieu of all other remedies, whether oral or written, express or implied. MIT's liability to the Participant in the event of any other claim by Participant shall be limited to the amount of the Participant's duly paid Fee. In no event shall MIT, ERCIM, KEIO, and/or BEIHANG be liable for any indirect, incidental, consequential, or special damages, including lost profits, sustained or incurred by the Participant in connection with or as a result of its participation in the Business Group or under this Agreement.

108 | 109 |

8. Force Majeure.

110 | 111 |

If the performance of any obligation by MIT, ERCIM, KEIO and BEIHANG under this Agreement is prevented, restricted or interfered with by reason of natural disaster, war, revolution, civil commotion, acts of public enemies, blockade, embargo, strikes, any law, order, proclamation, regulation, ordinance, demand or requirement having a legal effect of any government or any judicial authority or representative of any such government, or any other act or event which is beyond the reasonable control of the party affected, then MIT, ERCIM, KEIO and BEIHANG shall be excused from such performance to the extent of such prevention, restriction, or interference, provided that MIT, ERCIM, KEIO, and BEIHANG shall use reasonable commercial efforts to avoid or remove such causes of nonperformance, and shall continue performance hereunder with reasonable dispatch whenever such causes are removed.

112 | 113 |

9. Export Controls.

114 | 115 |

The Participant acknowledges that export and/or re-export from the United States, France, or Japan of technical data, computer software, laboratory prototypes and other commodities ("Controlled Commodities") may be subject to the export control laws and regulation of the United States (including the Arms Export Control Act, as amended, and the Export Administration Act of 1979 revised in 1985), of France, and of Japan, and that such laws and regulations could preclude or delay export of such Controlled Commodities. MIT 's, ERCIM's, KEIO's, and BEIHANG'S obligation hereunder are contingent on compliance with such applicable laws and regulations. Neither party will directly or indirectly export across any national boundary, or communicate or transfer to any third party, any Controlled Commodities without first obtaining any and all licenses that may be required from a cognizant agency of the United States government or the French or Japanese authorities, and/or any and all written assurances from the Participant that it will not re-export or transfer such Controlled Commodities to certain foreign countries or third parties without prior approval of the cognizant government agency. While MIT, ERCIM, KEIO, and BEIHANG agree to cooperate in securing any license which the cognizant agency deems necessary in connection with the export, re-export, transfer or communication of any Controlled Commodities, MIT, ERCIM, KEIO, and BEIHANG cannot guarantee that such licenses will be granted.

116 | 117 |

10. Assignment.

118 | 119 |

Neither this Agreement nor any rights hereunder, in whole or in part, are assignable by the Participant without the prior written consent of the Hosts. Any attempt to assign the rights, duties or obligations under this Agreement by the Participant without such consent shall be a breach of this Agreement and shall be null and void.

120 | 121 |

11. Entire Agreement.

122 | 123 |

This Agreement, together with the process and license documents incorporated by reference, embodies the entire understanding between MIT, ERCIM, KEIO, BEIHANG and the Participant for Participant's participation in the Business Group, and cancels and supersedes any other agreements, oral or written, entered into by the parties hereto as to its subject matter.

124 | 125 |

12. No Modifications.

126 | 127 |

This Agreement may be amended only by a writing signed by MIT, ERCIM, KEIO, BEIHANG and the Participant.

128 | 129 |

13. Governing Law.

130 | 131 |

The venue and governing law of this Agreement shall be that of the Participant's Host, namely: For ERCIM Participants, this Agreement shall be deemed to have been entered into and shall be interpreted and governed in all respects by the laws of France. For KEIO Participants, this Agreement shall be deemed to have been entered into and shall be interpreted and governed in all respects by the laws of Japan. For Beihang Participants, this Agreement shall be deemed to have been entered into and shall be interpreted and governed in all respects by the laws of PRC. For MIT Participants, this Agreement shall be deemed to have been entered into and shall be interpreted and governed in all respects by the laws of The Commonwealth of Massachusetts and the United States of America. 132 |

133 | 134 |

14. Survivability.

135 | 136 |

The obligations of MIT, ERCIM, KEIO, BEIHANG, and Participant under Sections 3-13 of this Agreement shall survive expiration or termination hereof, and shall continue hereafter in full force and effect.

137 | 138 | 139 | 140 |

IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be signed by their duly authorized representatives, effective as of the day and year first above written.

141 | 142 | 143 | 144 | 145 | 146 | 158 | 182 | 183 | 184 |
For the four W3C hosts
____________________, 147 | Participant's Host
148 | 149 |


150 | By:___________________________
151 |       

152 | 153 |

Title:

154 | 155 |


156 | Date:_________________________

157 |
Participant 159 | 160 |


161 | By:____________________________
162 |       

163 | 164 |


165 |

166 | 167 |

Title:___________________________

168 | 169 |


170 | 171 | Address: _________________________

172 | 173 |


174 |               _________________________

175 |

176 |
177 | Email:___________________________

178 | 179 |


180 | Date:__________________________

181 |
185 |
-------------------------------------------------------------------------------- /proposals/cg-process.md: -------------------------------------------------------------------------------- 1 | # Community Group Process 2 | 3 | **Status**: This is a draft revision for discussion. Key changes from the [CG Process currently in force](https://www.w3.org/community/about/process/): 4 | 5 | * This revision of the process does not mention Business Groups, but that is mostly to focus discussion on Community Groups. This is not meant to imply anything about the future of Business Groups. 6 | * Dropped the CG Forum (not used for many years) 7 | * Dropped CG Council because it played no normative role. We should still have a CG Council for those interested in the evolution of CGs. 8 | * Dropped the use of the word "Report" 9 | * Dropped details related to specification requirements in this document; instead normatively refer to requirements already documented elsewhere (and which can be updated more easily). 10 | * Added 11 | * Explicit mention of other policies governing CGs. 12 | * Expanded group lifecycle 13 | * Make more explicit the goal of identifying and updating scope and standardization plans 14 | * More actions may be taken if a group has no chair or if there are issues with chairs. 15 | * Explicit mention that there is an appeal path for process issues, but no appeal path for technical decisions. 16 | 17 | ## Abstract 18 | 19 | This document governs participation in W3C Community Groups. For information about other types of groups in W3C, please see the [W3C Process Document](https://www.w3.org/Consortium/Process/). 20 | 21 | ## Summary 22 | 23 | Since 2011, the W3C Community Group program has hosted discussions about the Web and supported incubation of new technologies. Community Group Specifications are not W3C standards or part of W3C's standardization agenda, but Community Group Specifications that gain traction often do advance to [standardization at W3C](https://www.w3.org/policies/process/) or in other standards bodies. This document defines the processes that govern the creation and operation of Community Groups. In addition to this document, the following policies govern other aspects of participation in Community Groups: 24 | 25 | * [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/) 26 | * [W3C Antitrust and competition policy](https://www.w3.org/policies/antitrust-2024/) 27 | * [Community Group patent and copyright policies](https://www.w3.org/community/about/process/summary/) 28 | * [Guidelines to suspend or remove participants from groups](https://www.w3.org/guide/process/suspension.html), which this policy extends to Community Groups. 29 | 30 | W3C may, from time to time, update these policies or create additional [policies](https://www.w3.org/policies/) and the latest versions will govern aspects of participation in Community Groups. 31 | 32 | ## Community Group program management 33 | 34 | The Community Groups Program is managed by the W3C Community Development Lead, chosen by W3C management. The roles of the Community Development Lead are described throughout this document. 35 | 36 | For any questions about the Community Groups program, including discussions about the transition from a Community Group to a standardization group, please contact the Community Development Lead at team-community-process@w3.org. 37 | 38 | ## Participation in Community Groups 39 | 40 | Community Groups are open to all with no fee. 41 | 42 | ### Intellectual Property Policies 43 | 44 | The Community Group intellectual property (IPR) policies seek to balance the concerns of both implementers and participants who hold Intellectual Property. Please see the [Patent and Copyright Policy Summary](https://www.w3.org/community/about/process/summary/), which covers the [W3C Community Contributor License Agreement (CLA)](https://www.w3.org/2025/08/cla) and the [W3C Community Final Specification Agreement (FSA)](https://www.w3.org/2025/08/final). 45 | 46 | W3C has a preference for organizational, rather than individual patent commitments. Requests to participate in an individual capacity without a corresponding organizational commitment will be subject to approval by the W3C staff; such approval to be granted or denied in the W3C Staff’s sole discretion. See the [Guidelines for Evaluating Individual Requests to Participate in a Group](https://www.w3.org/community/about/process/guidelines-for-evaluating-individual-requests-to-participate-in-a-group/). 47 | 48 | When a participant resigns from a Community Group, they incur no new or further obligations after the date of resignation and maintain only those obligations already incurred, and that survive resignation from the Community Group, as provided in the CLA and, when applicable, the FSA. 49 | 50 | ### When participation issues arise 51 | 52 | We encourage participants to first work with the Chairs to resolve any participation issues. If more help is needed, please reach out to the Community Development Leads. If further help is needed, this process adopts the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/) and [Guidelines to suspend or remove participants from groups](https://www.w3.org/guide/process/suspension.html) for incident resolution and escalation. 53 | 54 | ## Lifecycle of Community Groups 55 | 56 | The following sections describe the lifecycle of a Community Group: **proposed**, **active**, **dormant**, **archived**. 57 | 58 | ### Proposed 59 | 60 | Anyone may propose a Community Group. A Community Group proposal must include: 61 | 62 | * A group name (not already taken by a Community Group) 63 | * A description 64 | 65 | If the group expects to publish Specifications, the description must make this clear. In addition, it is good practice to include in the description: 66 | 67 | * A statement defining the scope of any anticipated Specification. The scope of a Specification should be different than that of any other Community Group (but it may be the same, such as when two communities wish to explore two solutions to the same set of problems). 68 | * Any initial expectations about standardization plans. 69 | 70 | If scope and standardization plans are not known at the time of the proposal, they should be updated once the group has been created and that information becomes known. 71 | 72 | #### Grounds for rejection of a proposal 73 | 74 | The Community Development Lead does not formally approve proposals but may reject a proposal for a Community Group when the name or description are likely to cause offense or confusion, appear primarily intended for commercial purposes, are frivolous, or are overly broad. 75 | 76 | ### Active 77 | 78 | Once five individuals support a proposal and it has been reviewed by the Community Development Lead, the Community Development Lead launches the group. 79 | 80 | #### Chair(s) 81 | 82 | Each Community Group must have at least one Chair who is responsible for: 83 | 84 | * facilitating effective discussion and coordinating the group's activities; 85 | * ensuring that group decisions reflect those discussion discussion; 86 | * ensuring the group fulfills the requirements of Community Group policies and publication requirements, as well as the group's charter (if it has one). 87 | 88 | The participants of the Group choose their Chair(s). The Chair(s) are also the primary contacts for the Community Development Lead. The Community Development Lead may be consulted in cases where participants face challenges in Chair selection. 89 | 90 | The Community Development Lead may remove a Community Group Chair after reasonable attempts to understand any complaints and resolve issues. A Chair that has been removed by the Community Development Lead may not become Chair again in the same group without approval from the Community Development Lead. 91 | 92 | #### Charter 93 | 94 | A Community Group should (but is not required to) have a charter that describes the group's scope of work, deliverables, contribution policies, decision process, chair selection process, and charter amendment process. W3C provides a [Community Group charter template](https://w3c.github.io/cg-charter/CGCharter.html). How a group adopts its charter is decided by the group. 95 | 96 | If a Community Group charter exists, it must be publicly available and must not conflict with or modify this process, the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/), the [W3C Antitrust and competition policy](https://www.w3.org/policies/antitrust-2024/), the Community Group patent and copyright policies, or any other policies for Community Groups. 97 | 98 | The Chair must give actual notice to the participants of any material changes to a charter. Participants may resign from the group if they do not wish to participate under a new charter. 99 | 100 | #### Decisions and appeals 101 | 102 | Consensus is a core value of W3C and decisions by consensus play an important role in the [W3C standardization process](https://www.w3.org/policies/process/#consensus-building). In the Community Group program, consensus decisions are appreciated but not required, and participants should bear in mind that the goal of incubation is idea generation. 103 | 104 | The Community Group program is meant to be lightweight enough so that participants with divergent views can pursue them in a different Community Group. In some cases, however, such as when a Community Group Specification has gained significant traction, it may no longer be a viable option to develop a competing proposal. In this case, the standardization process (which offers stronger guarantees and governance mechanisms) may well be the proper venue for resolving issues. 105 | 106 | A participant who wishes to contest a process matter should first discuss it with the Chair(s). If doing so fails to resolve the issue, the participant may escalate to the Community Development Lead, who will work with the participant and Chairs to understand the situation and pursue a fair resolution. 107 | 108 | #### Meetings 109 | 110 | A Community Group is not required to hold meetings. However, if it does, then the Chair should ensure that: 111 | 112 | * the meeting is announced to the group in a timely fashion so that people can schedule attendance; 113 | * an agenda is posted; 114 | * meeting minutes are published, including topic discussions and decisions. 115 | 116 | #### Communications 117 | 118 | Although W3C provides some facilities to support group discussions (e.g., mailing lists), a Community Group chooses its preferred mechanisms. Technical work must be conducted in public and past discussions should remain available online (e.g., in email archives). Private channels may be used for administrative matters (e.g., where personal information is used for meeting planning). 119 | 120 | Participants must not send unsolicited commercial messages or other promotional activities for personal matters or for third parties. See the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/) and the [W3C Antitrust and competition policy](https://www.w3.org/policies/antitrust-2024/) for more policies related to communications. 121 | 122 | Community Groups must not refer to Community Group specifications as W3C standards, or otherwise create confusion about the status of work. Community Groups must not use the W3C logo in communications without the express permission of W3C. 123 | 124 | ### Dormant 125 | 126 | From time to time a Community Group may wish to communicate that its work has slowed (but not stopped) and set some expectations about when the group expects to become active again. 127 | 128 | All Chairs of a Community Group must agree that the group should enter the dormant state, and contact the Community Development Lead to move the group to that state. 129 | 130 | While a group is dormant: 131 | 132 | * People may still join or leave the group, and the chairs may change. 133 | * W3C will not generally invite the group to W3C events where other groups are meeting. 134 | * W3C staff will continue to monitor group activity but only expects to reach out to the group if regular activity is detected. 135 | 136 | To return to an active state the group must have at least one Chair, all Chairs must agree that the group should be reactivated, and they should contact the Community Development Lead, who decides whether to reactivate the group. 137 | 138 | ### Archived 139 | 140 | Once a group has completed its work, the Chairs should request that a group be archived. 141 | 142 | No less than 10 business days before archiving a group, the Community Development Lead must alert the participants. Once archived, no individuals may join, and discussions stop. However, W3C continues to make available information about archived Community Groups and their previous communications it hosted (if any). 143 | 144 | An archived group may be re-activated with the approval of the Community Development Lead. 145 | 146 | #### Grounds for staff to archive a group 147 | 148 | The Community Development Lead may archive a group for other reasons than a Chair request: 149 | 150 | * **No Chair**. When the Community Development Lead detects that a group has lacked a chair for 30 business days or more, they alert the participants that the group will be archived if no chair has been named within 30 business days. 151 | * **Inactivity**. The number of participants drops below 3 for an extended period, or because participant activity (e.g., as measured by communications among participants) ceases for an extended period. Dormant groups will, in general, not be archived due to inactivity. 152 | * **Time for a new home**. When a Community Group Specification has traction but the group expressly does not wish to advance it to standardization, the Community Development Lead will assist the group in finding a new home outside of W3C for the community, then archive the group and redirect people to the new home. 153 | * **Agreement violations**. When, in the judgment of the Community Development Lead, the group has committed a serious violation of policies governing Community Groups. 154 | * **Confusing communications**. If the Community Development Lead determines that a group or its participants show a pattern of creating confusion about their work or its status (including Specifications that do not conform to requirements for Community Group Specifications), the Community Development Lead may take steps to remedy the situation, including archiving the group. 155 | 156 | ## Community Group Deliverables 157 | 158 | Some Community Groups create deliverables, while others simply hold discussions. This process primarily includes requirements on one type of Community Group deliverable: **Community Group Specifications**. 159 | 160 | Non-Specification Community Group deliverables must be publicly available at no cost. This process does not include IPR or other requirements for non-Specification deliverables (e.g., code, test suites, or other documents that are not Specifications). 161 | 162 | ### Community Group Specifications 163 | 164 | A Community Group Specification is any document intended to enable interoperable implementation of a technology. In case there is any doubt about whether a Community Group deliverable is a Specification, the Community Development Lead makes a determination for the purposes of conformance to Community Group policies. 165 | 166 | #### Intellectual Property 167 | 168 | Contributions and licensing commitments are governed by [Community Group patent and copyright policies](https://www.w3.org/community/about/process/summary/). 169 | 170 | #### Lifecycle of Community Group Specifications 171 | 172 | When a Community Group incubates a specification, they should have an eye towards future standardization. The CG program is meant to support technology development up to a point (and for an extended period of time), but not to be a permanent home. 173 | 174 | The maturity stages in the lifecycle of a Community Group Specification are: 175 | 176 | * **Draft**: The Specification is in development in a Community Group. 177 | * **Snapshot**: This particular version of the Specification will not change. The label "snapshot" on its own does not indicate whether this is a stable version of the Specification that is actively in use and may still be in development, or a snapshot of the Specification that has been abandoned and is not in use. Critical details about the status of the work are found in the Specification. 178 | * **Transferred**: This Specification is no longer in development in this Community Group. It has been transferred to a standardization activity and that activity should be consulted for the latest status. 179 | 180 | #### Publication 181 | 182 | Community Group Specifications must not claim to be W3C standards or otherwise cause confusion about their status, in particular with respect to W3C Technical Reports. 183 | 184 | The Community Development Lead will separately document the [requirements that govern publication of Community Group Specifications](https://www.w3.org/community/reports/reqs/), including maturity stage information, boilerplate language, and style requirements. 185 | 186 | In cases where Specifications do not meet these requirements, after attempts to remedy the situation, the Community Development Lead may take steps such as making changes directly to the Specification, removing a Specification from the W3C Web site, or in rare cases, archiving a group. 187 | 188 | #### Transition to Standardization 189 | 190 | Some (but not all) Community Group Specifications advance to standardization in W3C or another standards body. 191 | 192 | A Community Group that is interested in standardization (at W3C or elsewhere) should contact the Community Development Lead who will organize a conversation about [Considerations when transferring a CG Specification for Standardization](https://github.com/w3c/cg-program/blob/main/transfer-considerations.md). 193 | 194 | A Community Group should document its standardization plans for a Specification as soon as they are made. W3C will provide guidance to help Community Groups communicate their standardization plans. 195 | 196 | After a Community Group has transferred a Specification for standardization, the receiving standards group takes over responsibility for that snapshot. When the Community Group and standards group seek further collaboration, the Community Group may continue to incubate new features of the technology. 197 | 198 | When a Community Group Specification has traction and the Community Group does not wish to pursue standardization, the staff will help support the group's migration to another venue. 199 | -------------------------------------------------------------------------------- /policies/process.html: -------------------------------------------------------------------------------- 1 | Community and Business Group Process

This document governs participation in W3C Community and Business Groups. For information about other types of groups in W3C, please see the W3C Process Document.

2 | 3 |

Summary

4 | Since the early days of the Consortium, the number of stakeholders of the Web has grown significantly, powerful collaboration tools have gone mainstream, and expectations about standards themselves have evolved. W3C’s “classic” process and Membership models meet the needs of some stakeholders, but not all. W3C seeks to offer larger numbers of developers, designers, and others passionate about the Web the means to build communities. 5 | 6 | This document defines W3C Community Groups, where anyone may develop Specifications, hold discussions, develop tests, and so on, with no participation fee. Community groups emphasize individual innovation and allow an easy way for innovation from individuals to move to the “classic” W3C standards process, which emphasizes broad consensus-building and implementation among global stakeholders. Community Groups that develop specifications do so under policies designed to strike a balance between ease of participation and safety for implementers and patent holders. The new offering complements the classic process and patent policy; it does not replace it. 7 | 8 | This document also defines Business Groups to increase participation by organizations that may not be primarily motivated by participation in W3C standards development but instead are interested in the application of W3C technologies to business problems, and in providing high-bandwidth input to the standards process. Business Group participants who are not W3C Members pay for staff resources, but the fee for participating in Business Groups is less than W3C Membership (and grants fewer benefits). 9 | 10 | These programs are managed by a Community Development Lead, chosen by W3C management. The roles of the Community Development Lead are described throughout this document. Since December 2018, Dominique Hazaël-Massieux is Community Development Lead. 11 |
12 | 29 |
30 |
System Update: As of 16 July 2015, the W3C Forum is no longer used. Instead, people may discuss proposed Community Groups via comments on the main Community and Business Group blog. 31 |

The W3C Forum is a venue for discussion of Web-related topics including development of specifications. People submit material (a “Community Submission”) to the Forum that they wish to be developed by a Community or Business Group. W3C reserves the right to refuse publication of a Community Submission, for instance if the material is likely to cause offense or confusion.

32 | Individuals who wish to participate in the W3C Forum — enter into discussion or submit proposals — agree to the general communications policies. Participants are responsible for making clear the copyright and patent terms of their submissions. 33 | 34 |
35 |
36 |

Community Submission Publication Policies

37 | Community Submissions must not use a style that will cause them to be confused with W3C Technical Reports. W3C may publish additional policies to govern publication of Community Submissions. 38 | 39 |
40 |
41 |
Community Groups are open to all with no fee. They are designed in particular to provide developers with a place to meet. 42 | 43 |
44 |
45 |

Creation of a Community Group

46 |

Anyone may propose the creation of a Community Group. A proposal is “complete” when:

47 | 48 |
    49 |
  • It includes a name for the group (not already taken by a Community Group) and a scope description. The scope should be different than that of any other Community Group (but it may be the same, such as when two communities wish to explore two solutions to the same set of problems).
  • 50 |
  • Five individuals support the creation of the group. The W3C Forum may be used to build this support.
  • 51 |
52 | Once a proposal is complete, W3C announces the creation of the group (which includes its software infrastructure). This date is called the “launch date.” 53 | 54 | The Community Development Lead does not formally approve proposals but may reject a proposal for a Community Group when the scope is likely to cause offense or confusion, appears primarily intended for commercial purposes, is frivolous, or is overly broad. 55 | 56 |
57 |
58 |

Community Group Operational Agreements

59 | A Community Group may adopt operational agreements (recorded, for example, in the form of a charter) that establish the group's scope of work, decision-making processes, communications preferences, and other operations. For example, the agreement could establish fair and reasonable criteria for accepting contributions in a specification, or set the group's scope of work (e.g., development of educational materials or discussions about future standards work at W3C). 60 | 61 | The following rules govern Community Group operational agreements: 62 | 67 | The person who first proposes a group may establish the group's initial operational agreements. Thereafter, the Chair determines the means by which the group adopts and modifies operational agreements. The Chair must give actual notice to the participants of any material changes to the agreements. Participants may resign from the group if they do not wish to participate under the new agreements. 68 | 69 | Note: W3C encourages groups adopt decision-making policies that promote consensus. 70 | 71 |
72 |
73 |

Joining a Community Group

74 | Anyone may join any Community Group. There are no participation fees. 75 | 76 |
77 |
78 |

Resigning from a Community Group

79 | W3C will provide a mechanism for Participants to resign from a Community Group. Participants that resign from a Community Group incur no new or further obligations after the date of resignation and maintain only those obligations already incurred, and that survive resignation from the Community Group, as provided in the Community Contributor License Agreement (CLA) and, when applicable, the Final Specification Agreement. 80 | 81 |
82 |
83 |

Community Group Chair(s)

84 | Each Community Group must have at least one Chair who is responsible for ensuring the group fulfills the requirements of this document as well as the group's operational agreements. The participants of the Group choose their Chair(s). The Chair(s) are also the primary contacts for the Community Development Lead. 85 | 86 |
87 |
88 |

Duration and Closure of a Community Group

89 | Once a Community Group has been launched, participants may continue to work indefinitely, until the Community Development Lead closes the group; see the grounds for closure. 90 | 91 | No less than ten business days before closing a group, the Community Development Lead must alert the participants. Once closed, no individuals may join, and discussions stop. However, W3C makes available information about closed Community Groups and archives of their communications. 92 | 93 | Closed Community Groups are re-opened following the creation process. 94 | 95 |
96 |
97 |

Grounds for Closure of a Community Group

98 | The Community Development Lead may close a Community Group in any of following circumstances: 99 |
    100 |
  • Chair Request. The Group Chair requests that the group be closed (e.g., as the result of a group decision, or on a certain date selected in advance by the group).
  • 101 |
  • Inactivity. The number of participants drops below 3 for an extended period, or because participant activity (e.g., as measured by communications among participants) ceases for an extended period.
  • 102 |
  • Agreement Violations. When, in the judgment of the Community Development Lead, the group has committed a serious violation of this policy, for instance exceeding its scope.
  • 103 |
104 | The Community Development Lead and Chair should discuss the group’s status before the Community Development Lead initiates closure. 105 | 106 |
107 |
108 |

Community Group Communications

109 | Each Community Group will have both public and non-public communications mechanisms. The former are for work, the latter for administrative matters (e.g., personal information used in meeting planning). 110 | 111 | To help Community Group participants adhere to the general communications policies, all participants (including the Chair) should help moderate discussion (for instance, to keep the group focused on relevant topics). 112 | 113 | In order to help the community track process, each Community Group is encouraged to summarize accomplishments, barriers to progress, or other challenges from time to time. 114 | 115 | All communications must be archived. 116 | 117 |
118 |
119 |

Community Group Branding

120 | Any Community Group branding (e.g., use of W3C name or logo in ways that may confuse the state of standardization, or technology-specific logo development) is subject to review and approval by the Head of W3C Marketing and Communications. 121 | 122 |
123 |
124 |

Community Group Meeting Policies

125 | A Community Group is not required to hold meetings. However, if it does, then the Chair must ensure that the following happens: 126 |
    127 |
  • the meeting is announced to the group in a timely fashion so that people can schedule attendance;
  • 128 |
  • an agenda is posted;
  • 129 |
  • meeting minutes are published, including topics discussions and decisions.
  • 130 |
131 |
132 |
133 |

Community Group Deliverables

134 | Community Group deliverables may be anything, including documents, test suites, tutorials, demos, code, discussion, etc. W3C will provide infrastructure to host discussions, code, specifications, test suites, and so on. 135 | 136 | The label "Community Group Report" refers to any document produced by a Group. Some Community Group Reports are Specifications. The following rules apply to Specifications: 137 |
    138 |
  • they must be publicly available.
  • 139 |
  • drafts are governed by Community Contributor License Agreement (CLA). W3C will provide a template for including copyright information.
  • 140 |
  • they must include the name the group that published the deliverables and link to a public page about the group.
  • 141 |
  • they must include a publication date.
  • 142 |
  • the history of Contributions (as defined under the CLA) must be archived permanently on the W3C Web site.
  • 143 |
  • They must include boilerplate language required by W3C (e.g., notice that Contributions are made under the CLA and that certain conditions apply).
  • 144 |
  • When published on the W3C site, they must not violate the W3C Privacy Policy.
  • 145 |
  • The content and style of the Specification must not cause confusion about its status, in particular with respect to W3C Technical Reports.
  • 146 |
147 | The following rules apply to Final Specifications: 148 |
    149 |
  • when they are published, W3C issues a call for participants to sign the Final Specification Agreement.
  • 150 |
  • they must be available in English.
  • 151 |
  • they must be published on the W3C Web site.
  • 152 |
  • Once a Final Specification has been published at a given URI, the Specification must not change.
  • 153 |
154 | Other types of deliverables must be publicly available and must be archived permanently. 155 | 156 | W3C reserves the right to refuse publication of deliverables, for instance if the material is likely to cause offense or confusion. W3C may publish additional policies to govern Community Group Specifications. W3C will provide style guides (and style sheets) for Specifications. 157 | 158 |
159 |
160 |

Community Council

161 | The Community Development Lead organizes a Community Council whose mission is: 162 |
    163 |
  • to promote the program and ensure that it functions smoothly, and
  • 164 |
  • to help the Community Development Lead fulfill the duties described in this document.
  • 165 |
166 | Initially the Community Development Lead selects the Council participants, with an emphasis on representation of diverse interests (public, W3C Membership, staff, other standards organizations, etc.). The Community Development Lead may develop other mechanisms for participant selection. 167 | 168 |
169 |
170 |

Inreach

171 | The Community Council works with existing groups in a variety of ways, including: 172 |
    173 |
  • Education of Community Group participants about doing work at W3C. This might involve creation of documentation, videos, or other tools. It might also involve chair training or providing good practice information to Chairs.
  • 174 |
  • Education of the broader community about the work done by Community Groups.
  • 175 |
  • Connections among groups that have shared interests. This might involve organizing joint meetings.
  • 176 |
177 |
178 |
179 |

Outreach

180 | The Council promotes broad inclusion and participation by newcomers in a variety of ways, including: 181 |
    182 |
  • Promotion of the program in online fora, at events, and in new communities.
  • 183 |
  • Encouraging the creation of language-specific groups, international participation, and online meetings.
  • 184 |
  • Efforts that help avoid confusion with W3C’s standardization process (e.g., through videos or other materials that help explain how to do work at W3C).
  • 185 |
186 |
187 |
188 |

Transition to W3C Standards Track

189 | Some (but not all) Community Group and Business Group Specifications are expected to serve as input to a Working Group. When a Community Group or Business Group wishes for a Working Group to adopt one of its Specifications, W3C facilitates the transition to the W3C Standards Track in a number of ways: 190 |
    191 |
  • Continuity of IPR commitments. The W3C Community Final Specification Agreement is designed to ensure smooth transition of IPR commitments from Community Groups or Business Groups to Working Groups.
  • 192 |
  • Continuity of participation. When a Working Group takes up a Community Group or Business Group Specification, non-Member employees may continue their participation in the Working Group for a limited duration while their employer makes the transition to Membership. The individual’s employer must have fulfilled the organizational patent requirements of the W3C Community Final Specification Agreement.
  • 193 |
  • Adoption by an Existing Working Group. If W3C has chartered a Working Group with a scope that encompasses the deliverable of a Community Group, the Working Group may adopt it without needing to recharter. Working Group charters created to standardize a Community Group or Business Group Specifications are be reviewed by the Membership following the usual process.
  • 194 |
195 | See How to transition work from a Community Group to a Working Group for more information. 196 | 197 |
198 |
199 |

Parallel Activities between a Community Group and a Working Group

200 | A Community Group may continue to exist after a Working Group has been chartered. The Community Group may wish to start experimenting with new ideas for a technology while the Working Group builds consensus and focuses on implementation of a stable set of agreed upon features. 201 | 202 | W3C recommends that once a Working Group has taken up a Community Group or Business Group Specification, the Community or Business Group should no longer develop the same material in parallel. Working Group licensing commitments are limited to the deliverables of the Working Group, so commitments do not follow text that is taken up by other groups (Community Groups or Working Groups). 203 | 204 |
205 |
206 |
207 |

Business Groups are open to all (including companies, non-profits, government agencies, research institutes, individuals), but parties that are not W3C Members pay a fee to participate. That fee is less than W3C Membership and grants fewer benefits. Business Groups are designed to provide stakeholders in particular industries with a forum to develop industry-specific applications of Web technology, to create a strong liaison between a particular industry and the Web community, or to solve an industry-specific issue without an initial assumption of which Web technologies apply.

208 | Business Group policies are the same as Community Groups except where noted below. 209 | 210 |
211 |
212 |

Proposing a Business Group

213 | Business Groups are proposed in the same manner as Community Groups, except that a proposal is not complete until at least five Organizations support creation of the group and the W3C staff has confirmed the expected staff resources will be available. Because goal of Business Groups is to grow the W3C community, we expect Business Groups to have a mix of Member and non-Member Organizations and individuals. 214 | 215 | Note: Business Groups are typically proposed by W3C 216 | staff after extensive discussion about strategic planning, budgeting, 217 | and resource allocation. For this reason, non-staff should not propose 218 | a Business Group without prior discussion with the Community 219 | Development Lead (who will coordinate staff discussion). Without 220 | sufficient discussion and coordination, the Community Development Lead 221 | may choose not to approve a proposed Business Group. 222 | 223 |
224 |
225 |

Joining a Business Group

226 | Joining a Business Group is the same as for a Community Group, except that: 227 |
    228 |
  • there is a participation fee (for organizations and individuals), and
  • 229 |
  • participants must also agree to the Business Group Agreement.
  • 230 |
231 |
232 |
233 |

Business Group Communications

234 | Each Business Group will have both public and non-public communications mechanisms. The participants decide which channel they use to conduct their work. If the group chooses to conduct its work on non-public channels, the group must maintain a public home page on the W3C site and must provide a public communication about their work at least every six months. This may take the form of a publication, a summary of work, or other form most suitable to keep the community informed of its progress. 235 | 236 |
237 |
238 |

Business Group Deliverables

239 | Deliverables are the same as for Community Groups, except the published documents are called “Business Group Reports”. 240 | 241 |
242 |
243 |

Staff Involvement in Business Groups

244 | Business Groups do not automatically receive staff contacts. W3C management may choose to allocate a small percentage of staff time to consult with Business Groups, facilitate cross-group communication, and help them accomplish their goals. The nature and degree of staff support may vary from group to group. 245 | 246 |
247 |
248 |
These policies are designed to encourage constructive participation and to balance IPR considerations with ease of participation. 249 | 250 | Community Group participants agree to abide by the terms and spirit of the W3C Code of Conduct. 251 | 252 | Violations of Community and Business Group policies should be brought to the attention of the Community Development Lead. The Community Development Lead is authorized to ban participants for violations of this policy or the signed Agreements, and also to reinstate them. Banned participants may appeal to the W3C CEO. 253 | 254 |
255 |
256 |

Summary of Copyright and Patent Policies for Community Groups

257 | The legal policies designed for Community Groups seek to balance the concerns of both implementers and intellectual property (IPR) holders. Please see the Patent and Copyright Policy Summary, which covers the W3C Community Contributor License Agreement (CLA) and the W3C Community Final Specification Agreement. 258 | 259 | W3C has a preference for organizational, rather than individual commitments. Requests to participate in an individual capacity without a corresponding organizational commitment will be subject to approval by the W3C staff; such approval to be granted or denied in the W3C Staff’s sole discretion. See the Guidelines for Evaluating Individual Requests to Participate in a Group. 260 |
261 |
262 |

General Communications Policies

263 | All Participants agree to the following general communications policies: 264 |
    265 |
  • Participants must have an identity within the community.
  • 266 |
  • Communications must not be disruptive. Participants must refrain from defaming, harassing or otherwise offending other participants or their organizations.
  • 267 |
  • Participants must not send unsolicited commercial messages or other promotional activities for personal matters or for third parties.
  • 268 |
  • Participants must respect confidentiality levels of communications.
  • 269 |
270 |
271 |
272 |
273 |
274 |
Community Development Lead
275 |
The individual responsible for the Community Group program. The Community Development Lead, appointed by the W3C Management, is responsible for: 276 |
    277 |
  • Monitoring the W3C Forum
  • 278 |
  • Managing escalation of issues
  • 279 |
  • Managing the composition and operations of the Community Council
  • 280 |
  • Serving as liaison to the W3C Staff (e.g., for outreach opportunities)
  • 281 |
282 |
283 |
Community Council
284 |
This task force assists existing community groups (e.g., in how the standards process works, accessibility input early in the development of the specification) and proactively seeks opportunities to engage with communities outside W3C, to find and communicate opportunities for liaisons.
285 |
Community Submission
286 |
Community Submissions are proposals made in the W3C Forum.
287 |
Community Group or Business Group Report
288 |
A Community or Business Group Report is a document (specification or other type) produced by a Community or Business Group.
289 |
W3C Forum
290 |
A single global public forum where anyone may begin to generate interest around new ideas.
291 |
292 |
293 |
294 | 295 | 296 | --------------------------------------------------------------------------------