Blink API owners positions on spec availability

[Rick Byers]

Hey,

We've talked off and on about this topic for years in various places but I couldn't find any canonical reference. What is the Blink API owners position on the availability of specs? To what extent are we less inclined to approve a feature to ship in Chromium if the spec is behind an expensive paywall? Should we say something explicit in the interop principles doc on this point, or (like IPR) is it explicitly out-of-scope for API owners analysis?

I'm not sure exactly how I feel about these questions myself, but let me start by taking the unpopular position (since it's the harder position to take). We should acknowledge that SDOs provide value for the ecosystem and need some way to fund that value, and for maximum ecosystem resiliency it's healthy that different SDOs approach funding in different ways (potentially including via pay-for-access specs). What matters for our goals isn't necessarily how available specs are, but how likely broad interoperability is in practice (including for small browsers and emerging new engines). For example, I wouldn't be too worried about approving a feature (say, for sake of argument, an image codec) that relied on a paywalled spec but had a defacto standard royalty-free reference implementation which in-practice all browsers were likely to share. I'd be much more worried about a feature with a free/open spec with restrictive licensing terms (even if that is out-of-scope for API owners to evaluate). 

But access to the spec and IPR is not the only thing that matters here, the other is how open to feedback and engagement the relevant standards process is. Maybe a paywalled spec with an active diverse community of maintainers is better than a free spec on someone's personal github with unclear governance? Then of course there is spec copyright - who cares if there's good governance if anyone can just fork the space elsewhere?

So as a strawperson proposal: API owners leverage their expert judgement to evaluate likely eventual interoperability without making a judgement call on the "right" ways for achieving that interoperability beyond our stated requirements of there being SOME spec and (ideally) a good conformance test suite.

Thoughts?

   Rick 

[Chris Wilson]

Earlier this summer, I wrote up an internal draft of "preferences for SDOs", but we didn't quite get to the external sharing stage.  It did explicitly say that specs should be freely available (among other things) in the principles (below).  These were ideals, not necessarily requirements.  In your codec example, Rick, I'd say those two examples are equally "somewhat undesirable", due to the long-term interoperability impact.  Happy to revive that work and bring it out more openly?

Principles for SDOs (draft)

• Available: standards should be freely accessible to all, with no access restrictions or charges to examine the standard.

• Open: participation in standard development should be open to all interested and engaged parties, including those participants without funding.

• Equitable and Transparent: Decision-making should be fair and based on consensus, the process transparent to participants, and no one party should dominate an SDO.  Standards should be developed based on technical merit judged by implementers as well as developers and users

• Freely implementable: ideally, intellectual property rights should be collected, and royalty-free licenses given.  In some cases (e.g. media codecs), IPR may not be royalty-free, and that may be outside our control; in that case licensing terms should be well-defined FRAND terms (fair, reasonable and non-discriminatory).

• Forkable: if an SDO becomes an unfit home for a standard, it is important to be able to take the work elsewhere, while giving credit where it is due.  This can be sufficiently achieved through copyright licenses that allow derivative works.

• Global: SDOs should enable global participation in their standards processes (through time zone management, etc), and ideally actively seek out and have global participation, as well as ensuring standards are fit for global use. 

[Rick Byers]

Thanks Chris. Yes, I think that would be helpful. I can't speak for the other API owners, but I'd personally be happy to refer to such a public doc as part of weighing the cost / benefit tradeoff of chromium features at I2P and I2S time. I agree with the way you've framed these as ideals.

Rick

[Philip Jägenstedt]

I think documenting these principles in public would be great, not least because it's clear that they still stand even if there are exceptions.

For ISO standards behind a paywall, neither Available or Forkable hold, which isn't great. If those standards fall into neglect, we'd have a problem that would be difficult to solve. At the same time, browsers do depend on things like https://www.iso.org/standard/83102.html with no obvious ill effects. So I think it's important to consider the tradeoffs and only block features on this concern if we're also willing to put in the considerable resources to take that standard to another SDO.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAFUtAY-RVehpEFKPEM6QGA_O_Aypa930B_c7Xtc34EFLnL%3DWpw%40mail.gmail.com.