AB/2014-2015 Priorities/w3c spec provenance

From W3C Wiki
Jump to: navigation, search

Raison d'être

This question seems to have come up at the June 2014 AB F2F meeting. In the minutes, Jim Bell is quoted as saying "there is quite a bit in our specs that is of unknown provenance". In a worst case scenario, a pseudonymous / anonymous / lying person introduces a patented idea into discussion but never joins a WG, and an editor unwittingly incorporates that idea into a spec that eventually becomes a Recommendation. Even if the editor and all WG members make binding patent commitments, the patent owner could seek royalties because he/she has not made an RF licensing commitment. Thus specs with contributed ideas of unknown provenance carry more patent risks than whose contributions can be explicitly traced to people who have made RF licensing commitments.

This has always been a known limitation of the patent policy in that previously unknown outside patent holders who do not make RF commitments can show up later to claim royalties from implementers of a W3C Recommendation. Arguably the recent changes that make W3C more open and agile increase this risk: making it easier to incorporate non-patented (or explicitly offered on RF terms) ideas would seen to make it easier for those who deliberately insert ideas covered by "submarine patents" to get them incorporated into W3C Recommendations. Perhaps more plausibly, a more open/agile process makes it more likely that patented ideas offered on RAND terms in other venues, or those unwittingly reverse engineered from proprietary technologies, could find their way into Recommendations. In any of these scenarios, implementers could be subject to litigation they thought was prevented by the W3C process/patent policy, undermining W3C's credibility.

The question this wiki page will capture is whether there are specific issues regarding process, tooling, or best practices that need to be resolved to ensure that spec texts that enter Working Groups are coming with sufficient IP coverage.

Open Issues

  • Suggestions for a more explicit methodology?
    • ArtB: I think the problem itself is mostly well understood and defined and the key issue is to educate the groups and technical contributors. As such, it seems to me that what is needed is some Best Practices and Guidelines to define the related expectations all technical groups should follow.
    • 2015-07-20 Tantek: I'm not sure the problem is actually well understood, as for example, there are no specific citations of when spec provenance has been a problem in practice.
  • Can we plausibly come up with recommendations to the AC/Team this session or is the goal just AB agreement on what the magnitude of the problem is?
    • ArtB: of course it's important to have a clear and broadly agreed Problem Statement. However, it seems to me this is mostly understood and the task at hand is to first define the BPs and Guidelines and then to do some Education and Outreach.
    • 2015-07-20 Tantek: Lacking specific examples / citations, I don't think the problem is "mostly understood", and thus am leaving this open until there are specific examples we can use to evaluate this issue.

Resolved Issues

The following issues have been resolved with follow-up and no objections.

  • Are there arguments for doing this in public?
    • ArtB: yes. Meticulous/thorough tracking of specification contributions is an issue for every group creating normative text that could be input for a W3C Recommendation. Thus, this is important topic for WGs and IGs but also for CGs. CGs participants, especially their Chairs and technical contributors should be encouraged to participate in this discussion and many CG members may not be able to participate in a Member-only discussion.
  • Should AB formally collaborate with PSIG itself or just recruit people with relevant expertise who may or may not be on PSIG?
    • ArtB: the later seems fine to me (i.e. no formal collaboration is needed). Just re-use the public-w3process or create a new list and announce it to PSIG.

See Also