Add free availability as a requirement for normative references #431

[svgeesus]

Following the advice in the W3C Council Report on the Formal Objection to the use of Normative References to ISO/IEC 18013-7 Annex C in the Digital Credentials API specification.

[nigelmegitt]

I suggest defining "freely available" somehow, or explaining what is meant by it. There are at least two potential ways that "freely" could be understood:

1. at no financial cost (e.g. a W3C specification)
2. easy to obtain (e.g. milk)

Of course it might also mean both things together, too.

I note that the referenced Council Report also is ambiguous about which meaning is intended, though in summarising the objection the Council was considering it uses the phrase "fee-gated" and proposes alignment with OpenStand, "at no cost and without limitation".

However OpenStand Principle 4 actually talks about fair terms (for implementation) and explicitly mentions FRAND, with the clear implication being that it might be reasonable for there to be a cost associated with implementing (and therefore by extension, potentially obtaining) a specification.

Given that it isn't really clear what "freely available" means, it's hard to see how TiLT can make an assessment of future similar references based on this phrasing.

For what it's worth, I have a strong preference that specifications referenced by W3C Recommendation track documents are "freely available" in the sense of both "at no financial cost" and "easy to obtain", although I can see that there might be exceptions occasionally.

[tidoust]

Thanks @svgeesus! That looks good to me.

@nigelmegitt, I note that the text narrows down the notion of "freely available" through "Specifications which are only available to members of some organization, only available by signing a legal agreement, or only available by paying a fee, are not considered freely available".

I think this takes care of the "at no financial cost" part. I'd be fine expanding the sentence to cover "easy to obtain" but has that been a problem in the past few years? If not, I would not worry about that.

(Note: we should share the PR with the AB for review before merging)

[svgeesus]

(Note: we should share the PR with the AB for review before merging)

Is there an AB github account or should I just at-mention a few key people?

[svgeesus]

I'd be fine expanding the sentence to cover "easy to obtain" but has that been a problem in the past few years? If not, I would not worry about that.

@nigelmegitt I'm trying to imagine a form of "hard to obtain" that is not covered by "buy it using swiss francs" (ISO) or "only available in printed form from this publisher who only ships to the US" (MIDI spec, a decade or so ago), both of which involve paying money. Or "must sign an NDA first" (MIDI specs in development but not released in final form).

I understand your point in the abstract, just trying to clarify what it would amount to in practice.

[svgeesus]

However OpenStand Principle 4 actually talks about fair terms (for implementation) and explicitly mentions FRAND, with the clear implication being that it might be reasonable for there to be a cost associated with implementing (and therefore by extension, potentially obtaining) a specification.

It does, but that aspect was already covered in the existing document, under Licensing.

[nigelmegitt]

It does, but that aspect was already covered in the existing document, under Licensing.

Sorry I buried my point a bit: the issue is that OpenStand principle text can be considered to include not just implementing but also obtaining the specification. That's different from Licensing.

[nigelmegitt]

trying to imagine a form of "hard to obtain" that is not covered by "buy it using swiss francs" (ISO or "only available in printed form from this publisher who only ships to the US" (MIDI spec, a decade or so ago), both of which involve paying money. Or "must sign an NDA first" (MIDI specs in development but not released in final form".

Those are the kinds of thing I meant, and they don't necessarily involve paying money directly for the specification - there can be indirect costs instead, like for postage or travel. This Douglas Adams quote comes to mind:

It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.

[nigelmegitt]

Thanks @svgeesus! That looks good to me.

@nigelmegitt, I note that the text narrows down the notion of "freely available" through "Specifications which are only available to members of some organization, only available by signing a legal agreement, or only available by paying a fee, are not considered freely available".

Thanks @tidoust for highlighting this. On re-reading, I realise that the key term is not "freely available" but "not freely available" (apologies screen reader users, that almost certainly sounds the same - I am suggesting that the word "not" is included within the term). Edit suggestions incoming.

[nigelmegitt]

Some proposals for addressing the discussion comments about "not freely available".

[nigelmegitt]

Getting closer...

[svgeesus]

Thanks for the helpful review comments so far.

@tidoust wrote:

(Note: we should share the PR with the AB for review before merging)

I asked for review from @torgo and @brentzundel

[svgeesus]

@tidoust

(Note: we should share the PR with the AB for review before merging)

We called for review two weeks ago, should we wait some more?

[hober]

r+ with nit that weakens the new requirement somewhat, and noting that the PR appears to be a draft.

Re: weakening the requirement, the rest of the text makes it abundantly clear that those attempting to include such a normative reference have homework to do.

[hober]

Suggested change

	In general, and consistent with the Modern Paradigm for Standards ([OpenStand principles](https://open-stand.org/about-us/principles/)), W3C does not allow standards-track specifications to make normative references to specifications which are **not freely available**.
	In general, and consistent with the Modern Paradigm for Standards ([OpenStand principles](https://open-stand.org/about-us/principles/)), W3C prefers standards-track specifications to refrain from making normative references to specifications which are **not freely available**.

[csarven]

"prefers", or similar language, isn't compatible under the "Requirements" section, and it also undercuts the following paragraph. The current text is consistent and logically necessary for the guidance that follows, so it seems accurate to me.