Non-normative changes

[annevk]

I was somewhat under the impression that non-normative changes could be contributed without signing the agreement (e.g., typos, URL fixes), but nothing seems to support this. Thus far it hasn't really been a problem, but I definitely have myself just walked away from a project that wouldn't accept a clarification in a README without a special dance.

[othermaciej]

SG briefly discussed this in a call today. No final conclusion, but here's some thoughts:

• There's defininitely no exception for non-normative changes in the current IPR policy.
• Being non-normative would mean that a change likely does not implicate patent rights, but it could still be covered by copyright. Our contributor agreement covers both patent and copyright.
• Some believe that certain kinds of changes are too trivial to be copyrightable. While a lengthy non-normative example likely is still subject to copyright, a simple typo fix or URL correction may not be.
• We currently don't have an exception even for changes that are so simple they are not.
• Many open source projects require an agreement of some form for any PR or patch, so the IPR policy is not necessarily wildly outside the norms of the open source community.
• We can ask counsel whether it would be appropriate to add an exception for trivial changes that are below the copyrightability threshold.

[domenic]

The main issue here is that for individuals who work in the field of web technologies, getting their employer to sign the CWA can be a significant hurdle. It is in this sense that the CWA is further from the norms of an other open source projects' CLAs. Thus, first-time contributors may be discouraged from contributing even small, non-normative fixes to WHATWG standards, which hurts the vitality and growth of the community.

I think it would be ideal if we could accept such contributions without requiring a signed CWA. (Although we would still encourage it as much as possible.)

I could even imagine getting folks hooked on contributing small fixes, so that when they want to contribute a normative change, they can more strongly advocate to their employers for signing the CWA in full.

An alternate solution would be adding a third option to the CWA, which signs you up for no workstream patent commitments but does sign you up for copyright, so that it would act more like a regular open source CLA.

[othermaciej]

For trivial contributions and non-normative contributions, we might be able to get agreement that such changes can be accepted with no agreement.

For non-normative but also non-trivial contributions, a copyright-only CLA seems like the best approach. Maybe this is also good enough for non-normative and trivial contributions.

I somewhat worry that anything like this will be used to evade patent licensing requirements.

[othermaciej]

For reference, are there any specific contributors who were unable to contribute but would have been helped by this change? Concrete examples would help.

[michaelchampion]

Yes, concrete examples would help.
This exposes a dilemma: We want to make it as easy as possible for people willing/able to make patent commitments to participate while making it as hard as possible for people unwilling to make patent commitments to influence the specs. If there are a significant number of real people who are willing to participate but unable to convince their lawyers to sign the CWA (or unwilling to invest the time dealing with their management to drive such a decision with the lawyers), the SG needs to deal with that reality somehow.

Or to put it another way: We hoped that it would be no harder for experts in web technology to sign the WHATWG CWA than it is to sign typical open source CLAs. If that's not true, we have a problem. But if it's just a matter of educating people that open specs expose the same sorts of copyright and patent issues that open source projects have come to grips with using CLAs, then we need to work on that. So are there people employed in the field of web technology whose employers allow them to sign OSS CLAs but not the WHATWG CWA? If so, how could we mitigate that?

[sideshowbarker]

For reference, are there any specific contributors who were unable to contribute but would have been helped by this change? Concrete examples would help.

Me.

Specifically, I raised whatwg/html#3434 on January 31st but it’s now indefinitely blocked on the general CWA issue and specifically #62 and/or this issue.

And that PR is sort of the most non-substantive change that could be imagined. It’s just updating the URLs for a couple spec/references that have moved to new locations.

And while that change is kind of at the extreme range of non-substantiveness among the changes I have contributed to the HTML spec so far, most (if not all) of the few-dozen changes I’ve contributed to the HTML spec so far have been non-substantive in terms of the intended purpose of the CWA — in that most (or nearly all of them) have been changes to parts of the spec other than the parts that define UA requirements.

To be more specific: The changes I contribute are mostly either purely editorial or are changes to the parts of the spec that define document-conformance requirements aka “authoring” requirements — a lot of which are driven by related work I do in updating and maintaining the backend for the W3C HTML Checker (validator).

Anyway, as far as I can see, none of those kinds of changes have anything to do with content that relates to anything that could infringe on any patented essential claims that might exist. So the CWA (in its intent at least) is irrelevant to those changes.

That reminds me: I think this issue shouldn’t be about non-normative changes vs. normative changes. Instead it should be about changes to content that could infringe on any patented essential claims that might exist vs changes that don’t.

It seems to be that better wording to use for that distinction is “substantive” vs ”non-substantive”. I’m pretty sure that in some of the corresponding process/tooling the W3C uses, that’s the actual term.

But regardless of terminology, such a distinction is important. I say that because the changes that I make to document-conformance requirements in the spec are in fact normative changes — because just like the statements of UA requirements, those document-conformance requirements are stated with RFC 2119 normative language. They just state them for a conformance class other than UAs.

But if we were to define “substantive” to mean “changes to content that could infringe on any patented essential claims that might exist”, then those changes I make to document-conformance requirements, while normative, would be considered non-substantive (and so not require any CWA commitment).

[sideshowbarker]

It now occurs to me that one very concrete way we can categorize a change is by looking at whether the change is of the kind that necessitates writing new web-platform-tests/testharness.js tests — or changing existing web-platform-tests/testharness.js) tests.

We’ve already had a contribution requirement in place that if a change introduces a new algorithm or whatever — or changes an algorithm — for a feature that’s exposed to Web content in such a way that web-platform-tests/testharness.js tests could be written or updated to test UA behavior for it, then such tests must be written or updated for it before it can actually be merged into the spec.

So to judge whether a particular contribution requires CWA signing, one concrete way we could make that determination is on the basis of whether it requires new wpt tests or updates to existing wpt tests.

By that metric, then, changes made to, e.g., document-conformance requirements — while normative — don’t require new wpt tests or updates to existing wpt tests, and so don’t affect anything that’s exposed to Web content, and so couldn’t infringe on any patented essential claims that might exist.

[sideshowbarker]

For reference, are there any specific contributors who were unable to contribute but would have been helped by this change? Concrete examples would help.

That seems a bit like begging the question (or whatever the proper rhetorical term is). I mean, if somebody has a specific change they want to contribute but in the process of preparing a patch/PR or issue they see the CWA requirements and decide they’re not going to be able to comply with the obligation to get their employer to sign, then we may (likely) not ever hear from them. I think there’s a high chance that at that point they just say the hell with it — especially if all they want to submit is a fix for a typo or something else non-substantive — and they just walk away. And when that happens we lose a contributor without ever even knowing we had one.

And we’ve only had the CWA requirement in place for a very short time, so I think at this point we really shouldn’t expect to have a lot evidence (concrete examples) of people unable to contribute due to it.

Also rather than the question are there any specific contributors who were unable to contribute but would have been helped by this change, I think another way of looking at it would be to consider how many of, say, the 100+ people who had already contributed to the HTML spec before we put the CWA requirement in place wouldn’t have been able to contribute if the CWA requirement had been in place at the time. Or now won’t be able to contribute further.

The way we could find out is by asking some of them.

Otherwise, as far as data/evidence on how the current CWA requirement is affecting contributions, I think — for the reason I stated at the beginning of this comment — that it’s very hard to collect that data. So I believe that with the current CWA requirement in place, the evidence we’ll likely instead end up seeing over time is just a general apparent decrease in the rate of contributions we’ve now been getting relative to the rate of contributions we got prior to the CWA requirement being in place.

That’s something actually measurable but given that it would take time to get the data to measure it, I hope we’d not end up waiting to make any changes until we’ve seen that measurable decrease in contributions that I at least personally think we’re likely to up with if we don’t make some refinements to the (new) current requirements we’re placing on contributors.

[dbaron]

I think tying to something like whether web-platform-test changes are needed supposes a meaning of "implementation" that I don't think is justified. I think "implementation" in its original sense (of putting something into use or practice) applies to both the producers and consumers of a format, even if in recent years we've taken to talking about the implementations of file formats used on the Web as being only the software that consumes the format, and not software or individuals that produce the format. In the definition of Essential Claims or Essential Contribution Claims I've always interpreted "implementation" as the original (broader) meaning.

[othermaciej]

I agree with @dbaron. Normative requirements on authors, authoring tools, or conformance checkers can also potentially involve patents.

I also need to stress that under the new IPR policy we need a copyright grant. So essential patent claims are

@sideshowbarker the SG has discussed your other issue and definitely wants to find a way for you and other W3C staff members to be able to contribute. We have had private discussions with our lawyers about the topic. I suspect excluding some kinds of contributions from CWA coverage will actually be harder than finding a solution for W3C participation.

---

Finally, just so it's clear for the record, we have talked about a few different categories of contribution:

• Changes that affect normative implementation requirements. These clearly require both patent and copyright grant to enable us to uphold the WHATWG Principles. They also need tests in WPT.
• Changes that affect normative requirements for authors or other conformance categories besides mainstream UAs. Likewise require both patent and copyright. Patents can affect software other than browsers. May not need WPT tests.
• Changes that don't affect normative requirements but which contain significant original material. Requires at least a copyright grant. But we may be imposing a tricky judgment call on editors to ask them to judge whether something is potentially pulling in new essential patent claims. Current IPR policy does not require editors to know or decide anything at all related to patents.
• Changes that don't affect normative requirements and which are so trivial that perhaps they wouldn't even be considered copyrightable subject matter. Might not require any grant, but creating this category is potentially risky.

I'd like to make the bar to contributing as low as possible. But making major changes to the contributor agreement is something that lawyers are extremely wary of, and we would not want to do it without their input.

[annevk]

I think basically what I'm looking for is something similar to https://www.w3.org/2018/Process-20180201/#correction-classes. In W3C repositories it seems pretty common to dismiss the IPR bot for something that's non-substantive.

On the other hand, thus far we haven't had much of an issue getting folks signed up, so maybe we can leave this be for now and have a slightly higher bar.

[vfournier17]

@annevk I would agree. Let's see if we have an actual problem to solve before trying to come up with a solution.

[domenic]

We do have an actual problem, don't we? See upthread; specifically #63 (comment).

[othermaciej]

@domenic We have a problem for the specific case of W3C staff, which the SG is endeavoring to solve through back channels.

While it might make sense to make an exception to the requirement to sign CWPA for certain classes of trivial / non-copyrightable changes, I don't believe it would actually solve the problem cited in that comment, which includes a desire to make changes that are clearly copyrightable and in some cases normative (just not for implementations).

I think our best path here is to continue to work through the issue with W3C leadership, and watch for other problem cases to come up.

[ediosyncratic]

This discussion seems to have been prompted by my recent contribution, although sideshowbarker's experience is different.
Let me, at least, address the issue as it relates to my contribution.
I initially reported a typo fix as an issue.

The issue report was trivial enough that I imagined someone on the regular team (for whom contributor agreement issues would be no problem) could handle turning the error report into a contribution with minimal effort.
Generally, any change that isn't susceptible to copyright can probably be handled in such a manner; the external without a contributor agreement reports the issue, someone internal resolves it.
In the Qt project, I'm internal; and I routinely turn issues reported in our Jira into patches, thanking the isssue reporter for pointing it out, rather than asking them to go through the rigmarole of signing our CLA, just to contribute a trivial patch.

Only when asked to offer a patch did I do so; and that's when my need to (spend some time reading and then) agree to your T&Cs arose.
It may be a better plan to simply have internals fix trivial issue reports, rather than having a normal policy of asking for a patch from the issue reporter (as appears to be the case).
Of course, when the suggested change is big enough to implicate copyright, it's necessary to get the issue reporter to sign the contributor agreement anyway, at which point it makes sense to ask them for a patch as well.
At the very least, when asking the issue reporter for a fix, check whether the issue reporter has already signed a contributor agreement; if they haven't, take the time to link to it while asking for a patch and make clear that it's OK to leave it to internals to handle if that's potentially a complicator.

If nothing else, the time-cost of reading all that legalese (on which, incidentally, I would report several more issues, if I could see where to do so) dwarfs the rest of the cost of making a single trivial contribution.
Reporting the issue on your bug-tracker is an easy and lightweight way to contribute, with minimal legal implications; fixing the issue is a big deal, even when the source-change is trivial, if it involves spending a significant fraction of an hour reading legalese.

As to "non-normative", that's a misleading factor.
A non-normative change may be susceptible to copyright; so you do need to ensure that anyone contributing such a change has executed your contributor agreement.
You need to be free to publish the derivative work of their change.
What matters is whether the change is susceptible to copyright.
When it is, you should probably not ask an issue reporter to fix it themselves; if only because turning a reported issue ("the quoted text is a typo") into a fix may be what tips a change over the threshold into being (just) susceptible to copyright.

So, while it may make sense to have an exception to the requirement for a contributor agreement when the change isn't susceptible to copyright,
I think the better resolution of the situation that's brought this discussion up would be to
revise your default response to trivial issue reports.

That would, at least, have avoided my complication; I can't speak for sideshowbarker's; that may be trickier.

[ediosyncratic]

As for the specifics of why a potential contributor may have an issue with enacting a contributor agreement, I think you're focussing on the things your lawyers care about and forgetting some pretty big things the potential contributor cares about.

Consider this break-down of rough estimates of the time it took me to make my contribution:

• O(minutes) to report the initial issue (including finding where to do so)
• O(minutes) to clone the repo
• O(seconds) to fix the typo
• O(minutes) to push the fix and turn it into a pull request
• O(hour) to read the contributor agreement

That last item is sufficient to put off some contributors all on its own.
See annevk's comment "I definitely have myself just walked away from a project that wouldn't accept a clarification in a README without a special dance."

Aside from that, while reading, I discovered that if I'm employed to work on web technologies, it's not sufficient for me to register - I have to go via the corporate lawyers of my employers.
If I'd felt that was necessary, I'd just have added an O(weeks) item to the list above; that would definitely have put a stop to my contribution.
My reasons for contributing do not approach being representable, no matter how I might try, as enough to support a business case for our lawyers to even spend the time to reaad the CWA in order to evaluate whether my employer should sign up to it, much less for my employer to actually sign up.
So the "you can't join if we think your employer should" part of your CWA was the biggest potential obstacle, for me.

I resolved that by explaining to the editor why it might apply, so he could make an informed decision; and explained why I don't think it does apply, which he agreed with, so we got on with the job.
Folk entirely uninvolved in web technologies are unlikely to ever read these specs, much less notice things in need of being fixed.
So you can be fairly sure that your contributor pool consists of folk who have to, at least, address the question of which side of a poorly-defined dotted line they're on.
That is a cost, in its own right (it'll put some contributors off), even for those who decide (as I did) that their employer has no plausible claim on their contribution (I know my contract well enough to be sure of that) and no interest in interfering with their free-time contributions to public works.

So, while you do need to worry about patent issues and copyright, don't lose sight of the massive hurdles to contribution that your CWA puts in front of potential contributors.
The fact that you haven't heard from the contributors this puts off may just mean that they walked away without telling you.

[KiChjang]

To add to the list of concrete examples, I am also one of the contributors who is barred from landing a small change in whatwg/html#3844. I've since closed my PR as my company is not willing to willfully sign away their patent claims a priori. I do believe that there seems to be no reason to care about patents in non-normative changes, and having to sign this CWA is introducing unnecessary friction that ultimately causes me to abandon contributing altogether.

As it stands right now, I don't foresee my company relaxing patent claims anytime soon, and as a consequence this is a de-facto ban of my contributions to WHATWG. If I didn't know about the tracking issue here, I would not have left my comment, and WHATWG would not have heard from me about my experiences of being barred from contributing due to the CWA.

[sideshowbarker]

#63
Let's see if we have an actual problem to solve before trying to come up with a solution.

#63 (comment)
We do have an actual problem, don't we? See upthread; specifically #63 (comment).

Yes, to be clear, we still do have an actual problem — still, nearly two years now after this issue was first raised, and getting close to two years since anyone from the SG (or even any of the editors) posted any comments here about it or otherwise given any indication at all that the SG has even discussed it further and made any real attempt to try to find a solution.

#63 (comment)
We have a problem for the specific case of W3C staff, which the SG is endeavoring to solve through back channels.

No, we have a general problem — which the comment from @KiChjang at #63 (comment) is representative of pretty clearly, and which well articulates the consequences about the problem and its hidden costs:

having to sign this CWA is introducing unnecessary friction that ultimately causes me to abandon contributing altogether … this is a de-facto ban of my contributions to WHATWG … If I didn't know about the tracking issue here, I would not have left my comment, and WHATWG would not have heard from me about my experiences of being barred from contributing due to the CWA.

The W3C and TC39 have not found this to be a complicated problem to solve. What exactly is materially different for the case of the WHATWG that makes it any more complicated than just adopting something similar to what the W3C and TC39 already have in place?

As @annevk notes in #63 (comment), the W3C has already long had a policy to recognize particular contributions as ones that don’t require contributors to sign any agreement at all, and tooling for facilitating management of such contributions:

I think basically what I'm looking for is something similar to https://www.w3.org/2018/Process-20180201/#correction-classes. In W3C repositories it seems pretty common to dismiss the IPR bot for something that's non-substantive.

And at TC39 also, this problem is already solved: TC39 has a CLA that distinguishes between normative and non-normative changes, and signing the CLA is explicitly only required for contributors who are contributing normative changes; see the top of the form at https://tc39.es/agreements/contributor/, which says (emphasis added):

It is required in the following cases:

• To attend a TC39 meeting as an invited expert and participate in committee discussion
• To contribute a normative change to an ECMA-262, ECMA-402 or a proposal repository under the tc39 organization

So contributors have a much easier time contributing at the W3C and TC39, and the WHATWG is the single exception here — out of sync with all the work on the very closely-related specs at TC39 and the W3C — as far as having unilaterally chosen to put in place an arbitrarily much-stricter participant agreement that in practice blocks many potential contributors from participating at all, by failing to recognize and account for the clear difference between a contribution for a trivial typo and contribution for a substantive normative changes that affects implementation behavior.

Or to (re)state the “actual problem”: The participation requirements at the WHATWG are overly burdensome to potential contributors and unnecessarily and arbitrarily more strict than the corresponding contributor requirements at the W3C and TC39.

And while others here have taken time to try to convey how the harder requirements are costing the WHATWG, the SG has basically just sat on this for nearly two years now, and no one from the SG has ever clearly articulated any net concrete benefits the added strictness brings — in particular, any actual benefits to the wider WHATWG community — nor has anyone from the SG explained what if anything is materially different about the WHATWG case that would necessitate unilaterally putting more-burdensome contributor requirements in place that are at odds with the corresponding contributor requirements at the TC39 and the W3C, its closest peer organizations.

[KiChjang]

To be honest, I am more frustrated with the lack of communication by the SG than anything else. While it is understandable that the SG wants to avoid legal hassles as a consequence of accepting non-normative changes, the fact that we have heard no replies from the SG on this issue shows all contributors where their priorities lie, and it is this: "my contributions are unworthy, they are simply typo updates and link fixes, so be on my way and scram".

That may not have been what the wording that the SG members would have used, but actions speak much louder than words. What exactly is the problem on telling us what the status of this issue? Is it because other matters have priority over this for 2 years?

I'd like to add further that little papercut frictions like these is one of the reasons why I've halted my FOSS contributions. I used be a daily active contributor for Servo, but now I have over 2000+ GitHub notifications on that repository that I haven't gotten into reading. I used to be able to look over every individual issue and see if it follows the spec or not, and should any changes to the spec is required, I'd have either opened an issue or contributed the change myself. But seeing how volunteer work like this isn't being valued at all, I'd rather invest my time into other matters that pay my work a little more respect than what the SG is giving out.

[dbaron]

Sorry, we got preoccupied with the cooperation agreement with W3C, and didn't end up cycling back to this issue afterwards. We'll try to think about this set of issues more in the next few months, although I think this one in particular may be one of the more difficult ones.

One note on the comments above, though:

• I don't think https://www.w3.org/2018/Process-20180201/#correction-classes is relevant here; that covers rules for advancement through the stages of W3C's Recommendation-track, not contribution licensing. I think Non-normative changes #63 (comment) still applies.

[henceproved]

Like @dbaron mentioned, we have been discussing this, but it's been a very complex issue. But, no excuse for not communicating the status, so sincere apologies for that. We are working with our lawyers on a generalized policy, rather than having to make case-by-case exceptions (causing delays like this one, since a group of people and their lawyers need to come to a mostly agreeable decision). Since the generalized policy is proving to be more complex than we thought, we are discussing some alternatives now. We understand this is frustrating, and is not the response you all wanted to hear, but we will keep this thread posted with updates from here on out.

[bakkot]

I would also like to chime in as someone who has been frustrated by this, and to ask for an update.

I have been working on getting my employer, F5 networks, to sign the contributor agreement so that I can submit PRs. But that's not a trivial process at an organization of any size, and I'm not even sure they'll be willing to do so. Even if F5 is willing, that's likely to involve conversations with a lawyer, building out a process to get people added our Github org, etc.

Given that the PRs I have thus far wanted to contribute are entirely trivial bugfixes - e.g. this or this - it feels like signing this agreement not a good use of anyone's time (as has been pointed out before).

[foolip]

I'm self-assigning to reflect my action item from #125: "prune out patent info from current individual CLA add non-normative requirement bit and present plausible option to LWG for review"

To summarize the discussion that followed #63 (comment), it seems that because of https://whatwg.org/ipr-policy#copyright-license-grant being a license from contributors to the WHATWG to sublicense, and not a symmetrical license, just leaning on the GitHub ToS probably won't work. Instead, the next attempt is a trimmed version of https://participate.whatwg.org/agreement that concerns only copyright, which individuals could sign if they agree to license their contributions under those terms, and that they have the right to do so.

Showing what that would like in practice is part of figuring out together with legal counsel if that would work.

[cwilso]

https://www.w3.org/2021/Process-20211102/#substantive-change is a resource here.

[cwilso]

A possible definition for "trivial changes":

Trivial changes may be accepted without coverage from the agreement. A trivial change is one that fits one of the following categories:

• Makes no changes to the visible text content (for example, fixing broken links, style sheets or markup), OR
• Does not affect conformance (e.g. corrects a typographic error in a descriptive sentence), which should not change architectural or interoperability requirements for an implementation.

In addition, such changes should be small in scope (e.g., on the order of a few dozen characters changed at most); correcting non-normative code examples where the code clearly conflicts with normative requirements is fine, adding new non-normative code examples is not. If there is any doubt or disagreement as to whether requirements are changed, such changes should not be considered trivial.

[cwilso]

Revised definition for "trivial changes":

Trivial changes may be accepted without coverage from the agreement. A trivial change is one that fits one of the following categories:

• Makes no changes to the visible text content (for example, fixing broken links, style sheets or markup), OR
• Does not affect conformance (e.g. corrects a typographic error in a descriptive sentence), which should not change architectural or interoperability requirements for an implementation. Such changes should be small in scope (e.g., on the order of a few dozen characters changed at most); correcting non-normative code examples where the code clearly conflicts with normative requirements is fine, adding new non-normative code examples is not.

If there is any doubt or disagreement as to whether requirements are changed, such changes should not be considered trivial.

[annevk]

We have reached agreement on the above comment.

Next steps:

• Create a PR for https://whatwg.org/workstream-policy#contributions to incorporate Non-normative changes #63 (comment).
• Ask @domenic (hey!) about @whatbot tooling around this.

[domenic]

• Ask @domenic (hey!) about @whatbot tooling around this.

The easiest thing to do is nothing: the editors allow such PRs to get merged with a yellow circle instead of a green checkmark, saying "X has not signed up to participate".

The proper thing to do would be to add GitHub OAuth authentication to the /agreement-status page (e.g. https://participate.whatwg.org/agreement-status ), and if you're authenticated as an editor, you get an additional button to mark as non-normative. That doesn't seem too bad, but I've never set up GitHub OAuth on a website before, so there will be some initial cost.

[annevk]

@domenic I had another idea this morning. We could add a JSON resource to https://github.com/whatwg/participant-data that lists PR URLs that editors decided to approve. That also provides an audit trail for lawyers and the SG. (And then once we get bothered enough by this setup we can decide to automate changing the JSON with an authenticated button as you suggest.)