w3process
w3process copied to clipboard
w3c
Do we need a procedural track for "disclosure" documents?
SMPTE has a "registered disclosure" and IETF has "informational track" which (roughly) can be used to provide public documentation, for the good of industry, of practices and technologies that are not multi-vendor and/or not developed through a consensus process (e.g. they are developed by a single organization).
Does the W3C need a similar track?
Note: a motivation for this came up last year with the removal of Manifest's beforeinstallprompt. At first the feature was moved to an informative index, and then later it was moved into a new incubation repo (where it remains with little chance of getting multi-engine support).
I had been thinking about something related to this as well.
I think this would be useful, not only to allow enable givings a heads up to the community about something that was developed on the side, but also as a solution to cases where we attempted to develop something by consensus, then either failed to gather a sufficient number of implementers or have been blocked by formal objections against the technology being an inherently bad idea. When that happens, some of the time, some implementers may nonetheless insist on shipping the thing, and it may see significant adoption by authors/users.
We shouldn't call it a Recommendation if it doesn't meet our community's standards for a Recommendation, but as long as it is shipping in something that has meaningful marketshare, it would be good to have it be documented, to have the ability to file issues against it, to have HR concerns—if any— documented, etc. Some patent coverage might be good as well, although I suspect applying the existing patent policy as is would not work.
The logical way to do this would be by a change to the patent policy - which defines
- when a disclosure request is made
- what is required in a disclosure
- who is required to make disclosures on behalf of a W3C member
- that disclosures must be made public by published Working Drafts (i.e. Rec-track documents, whether or not they reach Rec).
But it doesn't define where the disclosure goes. That seems like a pretty small change, documenting in apprpriate lagnauge something that in practice is done through boilerplate and a web service that W3C set up "long ago" - see the Web RTC patent status as an example.
As far as I know, the existing system doesn't actually handle e.g. Community Group drafts (but I might be wrong - @caribouW3 @dontcallmedom ??). As I understand it, the request here is to have a standard documented procedure that can handle those as well as Rec-track documents, and I agree that would be useful.
@chaals Right, it does not cover work under simple CLA, only the Patent Policy. (BTW I'm no longer maintainer/systeam)
We have several mechanisms for things to be published. Included in that are Member submissions; Notes; CG reports; and of course the REC track. What are examples of documents for which none of these mechanisms could work?
@chaals I don't think I should have used the word "disclosure" as I am not talking about disclosing Patent Interest; I am talking about giving an avenue for the publication of single-vendor specs, specs that the W3C decided not to, or failed to, make into Recommendations etc.
I think that for single-vendor disclosures, we should probably set a policy about IPR and licensing: probably that the vendor explicity declare or attach what the terms are. I think that insisting on RF from that vendor might be counter-productive, but I think the quid-pro-quo of "we'll publish as long as you are transparent about licensing" might work.
A licensing policy for things that didn't reach Rec. state but that have multi-party input is harder. Um, much harder. They are Notes now. Maybe this second category is a tarpit we shouldn't wade into now?
I think that for single-vendor disclosures, we should probably set a policy about IPR and licensing: probably that the vendor explicity declare or attach what the terms are. I think that insisting on RF from that vendor might be counter-productive, but I think the quid-pro-quo of "we'll publish as long as you are transparent about licensing" might work.
I am not comfortable with using W3C as a clearing-house for non-RF technologies.
As I mentioned above, the existing member submission process may be used for issue #460. The existing process does not insist on RF (https://www.w3.org/Consortium/Patent-Policy-20200915/#sec-submissions), but in practice we have always encouraged RF submissions.
Perhaps Member Submission covers this, and we could simply clarify that this is the case?