Tracking issue: consider ECMA TC / W3C WG to publish standards

[lucacasonato]

We started discussing chartering a ECMA TC / W3C WG to be able to publish first party standards from WinterCG, namely to support the Socket API and Common Minimum API.

There was a bit of discussion at the last meeting, that I want to summarize here. We can use this thread as a starting point to discuss this topic further:

---

Summary of benefits of a standards body:

• has the ability to publish standards.
• CG can not publish standards, our charter prohibits this.
• CG has different licensing / copyright / patent implications than a standards body. This is effectively a CLA. With a standards body, we get something stronger: a royalty free patent on work published by the standards body.
• Standards specified by "real" standards bodies have a stronger sense of "standard" and "officialness".
• Anti-trust implications
• Standards bodies have a rules based system to permit members. This can help with inclusion.

Summary of benefits of ECMA specifically:

• Dan knows us how to work through ECMA.
• ECMA does not require arguing about chartering.
• Members have no resposibilities.
• Some of our primary members are not members of ECMA.

Summary of drawbacks of ECMA specifically:

• Members have to pay a membership fee.
• Inclusivity is reduced because of this.

There was some talk about keeping all incubation and discussion work in the W3C CG (WinterCG) and only moving technical review and standardization work of new specs into the TC/WG or relevant upstream standards bodies for third-party specs (like fetch, streams, crypto etc). This would allow us to bypass many of the inclusion issues that a TC/WG would pose, while still giving a path for self publishing.

[littledan]

A few things I want to add:

• Ecma has an invited expert program, to recover the lost inclusivity due to membership fees. Also, universities and other non-profits can join for free.
• Most WinterCG participants seem to be Ecma members already, and we haven't heard concerns about joining from the bigcorp folks that aren't in Ecma yet.
• I want to emphasize that the idea is that the technical development/incubation of stuff would still happen in WinterCG, with the future WinterTC focusing on validation and standardization, not making technical changes. This is the model that TC54 (CycloneDX) is using.

[jasnell]

I'm absolutely +1 on Ecma as a target here. Overall I tend to prefer their process and the proximity to TC-39 I think makes it a good fit.

[michaelchampion]

Summary of drawbacks of ECMA specifically:

Members have to pay a membership fee.
Inclusivity is reduced because of this.

Those drawbacks also apply to W3C.

I generally agree that ECMA is the logical place to standardize the Winter CG work. But there are groups, such as Web Assembly, that find a good balance between open innovation in a CG and more rigorous testing/polishing/standardizing in a Working Group. There's no reason that both aspects of innovation/standardization have to be under the same organizational umbrella. The real work happens in the community, not the organization.

[michaelchampion]

CG has different licensing / copyright / patent implications than a standards body. This is effectively a CLA. With a standards body, we get something stronger: a royalty free patent on work published by the standards body.

I'm not sure about ECMA's patent policy, but that's not quite an accurate description of W3C's . CGs require a commitment by everyone joining to offer a royalty-free license on any patents touched on by their own contributions to the CG. WGs require all members of the group to commit to RF licenses on "essential" patents touched on by the eventual Recommendation. But W3C members who aren't in the working group don't have to make that commitment.

In practice, nobody actually negotiates the RF licenses called for by the patent policy. And last I heard (before I retired from Microsoft 4 years ago) almost none of this has been tested in actual case law. So it all comes down to having a well-functioning community of collaborating competitors who swear off using patents to get competitive advantage in some technology area.

[littledan]

In a recent call, WinterCG resolved to seek standardization via Ecma. I've drafted a proposed scope, program of work, and working mode below. I'd like to review this in a future call, and if approved, submit to Ecma for the formation of the TC.

Scope

To refine and standardize programming interface surfaces and behavior which are useful across multiple ECMAScript environments which expand beyond web browsers. This group has a special focus on server environments for ECMAScript, but it may extend beyond that to other environments as well. The scope includes defining new interfaces, cross-referencing other sets of standards, and defining modified behavior for other existing interfaces.

Programme of work

• Standardize and maintain a “common minimum API” consisting of a set of standard interfaces, starting from web standards, which form a common base which is supported by all “WinterTC-compliant” environments, primarily targeted at ECMAScript server runtimes.
• Publish errata/patches to other standards to note their changes in behavior in WinterTC environments vs the original intended environment (e.g., web browsers), where it is not possible to make those changes “upstream” in the originating standard.
• Standardize new built-in modules for JavaScript environments for particular capabilities which are reasonable/appropriate only outside of the web context, e.g., raw sockets.
• Work with other standards bodies and community groups, especially the W3C Winter CG, TC39, W3C and WHATWG. In particular, much of WinterTC’s work will be originally drafted in WinterCG, to be further verified and standardized in the TC.

Working mode

WinterTC meets quarterly (or more frequently, as needed) via teleconference to identify appropriate specifications to develop into standards, typically as requested from W3C WinterCG. WinterTC is responsible for closely examining and verifying proposed specifications, and improving them through editorial changes. When WinterTC identifies a technical deficit or area for improvement in a specification it is reviewing, this information is passed to WinterCG, directing them to address the issue and bring a draft back to WinterTC. After all appropriate review and iteration, WinterTC may recommend specifications for standardization to the Ecma GA.

[jasnell]

That looks great @littledan !

[littledan]

Thanks for the positive feedback. It'd be great to have this draft charter #58 (comment) on the agenda for the next WinterCG meeting, which I guess is January 4th.

[littledan]

This charter was approved by WinterCG on January 4th. I will take the next steps from here, of bringing this charter for approval at the next Ecma ExeCom and GA meetings.

[Jack-Works]

I wonder, if the API is from W3C (e.g. fetch), can WinterCG "republish" it again on its own? Does this process require WinterCG to claim it owns the intellectual property in some form?

[andreubotella]

I wonder, if the API is from W3C (e.g. fetch), can WinterCG "republish" it again on its own? Does this process require WinterCG to claim it owns the intellectual property in some form?

For W3C, I think it depends on the spec. Some, like CSS specs, are published under open source licenses, whereas I think others aren't. But fetch is WHATWG, which is always open source (both CC-BY and BSD 3-clause).

[littledan]

@Jack-Works Hopefully we'll handle fetch through upstream collaboration with WHATWG. If that falls through, then we could consider publishing a fork/diff via Ecma, if we can work out the intellectual property issues.

[littledan]

@andreubotella Note that patent and copyright are both relevant here; standards are a little more complicated than "is it open source licensed". Let's try to do as much work as possible upstream.