W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: ISSUE-27: rel-ownership - Chairs Solicit Proposals

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 21 Jan 2010 09:56:15 +0200
Cc: Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>
Message-Id: <436BD36B-E65F-46ED-BA07-060776830B07@iki.fi>
To: Mark Nottingham <mnot@mnot.net>
On Jan 21, 2010, at 01:03, Mark Nottingham wrote:

> - The registry will be available in a machine-readable form, so that people can incorporate it in validators, etc. The machine-readable form is NOT available on the Web (to avoid load issues, such as those seen with W3C's DTD hosting); rather, they're available on a mailing list, so that vendors can redistribute it as they see fit.

When you say redistribute as they see fit, do you mean only verbatim redistribution or also distribution under a Free Software license if a vendor so sees fit?

Last I checked, the general IANA policy was that verbatim distribution of the registry files (with attribution) was permitted, but making changes or permitting downstream recipients to make changes (even if saying that the files have been changed) wasn't permitted. Thus, the IANA registry licensing (as it has been communicated to me by IANA) isn't Free in the Free Software sense.

This poses problems to Validator.nu, which aims to be a Free Software validator for HTML5. At present, the HTML5 validity definition depends on the IANA language subtag registry and on the IANA encoding name (charset) registry. (I'm not sure if the validity definition depends on the MIME type registry anywhere.)

Currently, Validator.nu implements language subtag validation (charset name validation is coming up). The Validator.nu source code repository contains Free Software code that can read a registry file in the IANA language subtag registry file format and perform validation based on that data. However, Validator.nu doesn't ship with a data file in this format, because of multiple reasons the simplest of which is that the repository is hosted on the condition that the software hosted is Free Software. (Other reasons to keep the software Free are relationships with Mozilla and potentially in the future with Linux distributions.) Instead, anyone who wishes to run a Validator.nu instance that performs language subtag validation in a way that matches the spec requirements needs to obtain a suitable data file in the right format from elsewhere (in practice from www.iana.org).

It's a pretty crazy situation that the non-Free component needed is an IANA registry file when the validator itself, OpenJDK under it, Linux under OpenJDK and Xen under Linux are all Free Software!

This scenario will repeat for charset names, but it doesn't have to repeat for rel values.

I think HTML5 shouldn't award the IANA a *new* registry dependency unless the IANA changes its licensing policy to be Free Software (and GPL) compatible in order to remove the above-described hindrance from Free Software implementations of HTML5 validation. (On the high level, this means permitting modifications, permitting distribution of modified versions downstream and permitting the downstream recipients modify and redistribute, too. It would be an acceptable condition to require modified copies to be marked as having been modified.)

I object to giving the rel registry to the IANA unless the IANA licenses all the registry files that HTML5 depends on under a non-reciprocal (but GPL-compatible) Free Software license that also qualifies as an Open Source license or dedicates the registry files to the Public Domain.

- -

P.S. Pre-emptive counter-argument to the most common counter-argument to what I just said:
I think a standard organization copyright on implementation components is an ineffective means for enforcing compliance. It would be trivial to make language subtag validation code to make the validator as a whole do an incompliant thing even when given a pristine verbatim copy of the IANA registry file. When standards org copyright is ineffective for this purpose, it doesn't make sense to pretend that it's effective and to cause other complications in doing so.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Thursday, 21 January 2010 07:56:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:00 GMT