Adjust language for getting patent policy comittments from non-participants#1129
Adjust language for getting patent policy comittments from non-participants#1129frivoal wants to merge 4 commits into
Conversation
nigelmegitt
left a comment
There was a problem hiding this comment.
Query about proposals originating from more than one party.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
The Revising W3C Process CG just discussed The full IRC log of that discussion<brent> subtopic: https://github.com//pull/1129<brent> Github: https://github.com//pull/1129 <TallTed> s/florian, you wanted to make a procedural point/ <Ian> Florian: PSIG is discussing this and has not yet converged. But one note is that prior to 2019 there was no formal rule about what to do regarding non-Member contributions , and the PP FAQ explained that it's the responsibility of a WG Chair to do the right thing. In 2019 a formal rule was introduced but the PP FAQ was not updated. <Ian> q+ <Ian> Brent: My first reaction is that the PSIG should update the FAQ <brent> ack Ian <Ian> Ian: Two areas of concern for me include (1) where rules should reside [IMO, should not be in the process] and (2) who has responsibilities (e.g., Chairs v. Team) <Ian> Brent: Since PSIG is discussion, let's await their findings. <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/14-w3process-minutes.html Ian |
|
The Revising W3C Process CG just discussed
The full IRC log of that discussion<brent> subtopic: https://github.com//pull/1129<brent> Github: https://github.com//pull/1129 <Ian> Florian: The core is probably not being disputed. I think we should converge on text to bring to PSIG. <Ian> ACTION: Florian to create a draft that he feels best represents consensus of the thread to present to PSIG <Ian> present TallTed <TallTed> q+ <Ian> TallTed: I think we should emphasize "secure" rather than "request"; ok for that to be another pull request <brent> ack TallTed |
This makes sure that we seek commitments to the patent policy from the the people who are originating the substance of the change being offered, rather than from those who are doing the mechanical work of offering them. Note: This aligns with current Team practices and existing tooling. Addresses w3c#903
|
The Revising W3C Process CG just discussed The full IRC log of that discussion<brent> subtopic: https://github.com//pull/1129<brent> Github: https://github.com//pull/1129 <Ian> Florian: Last time I said I would combine comments into a canonical text (done) and sent to PSIG (done). Now we await PSIG replies so let's leave open. |
|
I am convinced that sharing information about who was involved in a contribution would be a valuable disclosure. I think the requirement in the process document could stop there. Once there's a disclosure, another regime kicks in. |
|
The Revising W3C Process CG just discussed The full IRC log of that discussion<brent> subtopic: https://github.com//pull/1129<brent> Github: https://github.com//pull/1129 <Ian> Florian: We've been talking in the PSIG about non-participant contributions. <Ian> ...currently the expectation is based on "who creates the PR" instead of "who comes up with the idea" <Ian> ...PSIG has not yet made a decision <Ian> ...they raised 2 sub-problems <Ian> ...if it's a class 3 change, we need to add the person to grant a license. <Ian> ...if it's a new feature, not only must we ask but we must secure the license. <Ian> ...the point that was made is that this is a must without an "or else" <Ian> ...if we want a license but don't have one we may need some flexibility (e.g., reject outright or kick off a PAG) <Ian> ...another question relates to tooling -- if a submitter is a participant in a WG, we don't ask them if somebody else made up the idea. <hober> q+ plh <hober> ack florian <hober> ack plh <Ian> q+ <Ian> Florian: We could add language that when you contribute you will indicate that you are the author of the work or, if not, who is. <Ian> PLH: We don't block on pull requests from individuals who are employees of Members who are in the group <brent> ack Ian <tidoust> Ian: Is the question about essential claims? <tidoust> ... If I'm contributing something and someone else had the idea, I do have a disclosure obligation. <tidoust> Florian: Only if you're aware of a patent. <tidoust> ... For group members, patent policy makes them license patents in the end. <tidoust> ... For others, we ask them to agree with the patent policy when they submit a change request, nothing happens if the change request is made by a group participant on behalf of the non-participant. <tidoust> ... The disclosure obligation is only when you're aware of the existence of a patent, not about hypothetical cases where there might be a patent. <tidoust> Ian: There are also non-members who have essential claims on things we do. <plh> -> https://www.w3.org/guide/github/repo-management.html#how-pull-requests-get-handled How Pull Requests Get Handled <tidoust> ... The reciprocal grant usually helps there. <tidoust> ... What you're saying here is that this would be enough for this case. <tidoust> Florian: I think it's not a fatal risk, but a bit of a weakness that could be fixed easily. <tidoust> ... At least we'd get the opportunity to know that somebody else helped author. <tidoust> Ian: The PR could just say: disclosure obligation when you contribute something. Elsewhere, we could look into guidelines. <tidoust> Florian: Going further probably requires a PSIG discussion or an AB discussion. <tidoust> Brent: So next step is getting feedback from PSIG. |
|
@ianbjacobs One option worth considering is DCO developed by The Linux Foundation. It seems reasonable these days to require that:
I'm not sure if these requirements would cause problems for any potential contributors. I'm not aware of any such problems. ToolingThere's a git config setting that automatically adds the sign off to all commits made on the command line. Oddly the GitHub desktop app doesn't support it (yet?). From an enforcement perspective, the Linux Foundation has developed a useful GitHub application called DCO-2 that can be used to stop pull requests from being merged if they include unsigned commits, on repos where it is installed. There don't appear to be any funding requirements, but it might be polite to mention to them if we're going to adopt it. Patent policy impactsThe DCO 1.1 text explicitly declares that the contributor certifies that they have the right to submit it under the terms of the open source license that applies. So I think that means that they take on the responsibility, but I'm no patent policy expert! |
I don't think that works. Having the right to submit is a copyright question. What we're looking for here is a royalty-free patent commitment.
We have one already: when a contributor who's not a member submits something, they're asked to make the appropriate commitments, so is anyone else identified as a contributor. This proposed PR is not a request to change that practice, but to update the Process to back up that practice.
I disagree. Merely knowing who contributed, if we were to have no further requirements, does not mean we would get disclosures about any essential claims they may have. (a) They may not be aware of which patents they have, and (b) if they're not members, they are not obligated by the patent policy to give disclosures even if they are aware. That would seem like a step backwards from the current process, which requests (for class 3 changes) and requires (for class 4 changes) the submitter to commit to royalty-free patent commitment for any relevant essential claim they may have. The goal of this PR is to extend this requirement to contributors other than the submitter (which is already supported What may well be missing here is a rule about how these other contributors become known. I think we might want to add something along the lines of
Remedies for violations of this "must" may be somewhat limited, but would at least include the possibility of disciplinary sanctions. |
I don't have legal analysis on this, but my reading is it goes further, and that the DCO declaration matches the license in the code to which the contribution is being made. That could be restricted to copyright, or it could go further. For example, if the license says that the code is free to reuse (i.e. open source), that sounds like it goes beyond copyright and that the contributor is certifying that their contribution is also free to reuse in the same way. The current W3C licenses do essentially talk about copyright, but I guess we could go through a process to amend it to include requirements about IPR of the contents and algorithms contained within them, too. I am already sensing that this may strike terror into the hearts of those with more experience than me 😉 .
That's good, however it is a different approach - it's less pro-active, in the sense that the contributor can submit something and later make the commitment, as opposed to being required to make the commitment in order to submit anything. Just to be clear, I'm not saying the DCO approach is clearly the best fit for W3C. Rather, I think it's worth considering in the scope of alternative options. |
I am struggling to understand the true distinction between a lowercase, italic, non-RFC2119 "must" like that above, and an uppercase, non-italic, RFC2119 "SHOULD", if indeed there is any distinction. I do not think it worth the guaranteed misunderstandings to use both the lowercase and uppercase forms of the RFC2119 terms. There are plenty of alternative words to use when the full uppercase RFC2119 meanings are not desired. |
|
My intent was to suggest an RFC2119 "must" |
This makes sure that we seek commitments to the patent policy from the the people who are originating the substance of the change being offered, rather than from those who are doing the mechanical work of offering them.
Note: This aligns with current Team practices and existing tooling.
Addresses #903
Preview | Diff