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

[TallTed]

Sorry, overlooked this last round. GitHub tried to add another blank line here. Don't know if it's a CR or an LF. Probably still need those config files described elsewhere.

Suggested change

At a high level, when a W3C specification has normative references to other documents the Team considers four factors: stability, schedule, licensing, and availability. Any of the factors described in this document are fodder for Team consideration. No single factor is decisive. Different cases will involve different combinations of these factors. The Team may consider other factors not listed in this document as well; e.g. the likelihood that W3C may wish to submit the Recommendation to ISO and the PAS criteria for normative references.

At a high level, when a W3C specification has normative references to other documents the Team considers four factors: stability, schedule, licensing, and availability. Any of the factors described in this document are fodder for Team consideration. No single factor is decisive. Different cases will involve different combinations of these factors. The Team may consider other factors not listed in this document as well, e.g., the likelihood that W3C may wish to submit the Recommendation to ISO and the PAS criteria for normative references.